Enterprise Architecture in Denmark

Transcription

[Master Thesis – December 2006]
0H
Enterprise Architecture in Denmark
- Trends in business driven IT
within the public sector of Denmark
Supervisor: John Gøtze
Student: Flemming Hald
Enterprise Architecture of public Denmark
Master thesis, December 2006
ABSTRACT.............................................................................................................................................. 6
1H
270H
INTRODUCTION ................................................................................................................................... 7
2H
271H
BACKGROUND ...................................................................................................................................... 8
3H
27H
INTENDED AUDIENCE .............................................................................................................................. 8
STRUCTURE OF THE THESIS ..................................................................................................................... 8
RELATIONSHIP BETWEEN THE TWO REPORTS .......................................................................................... 9
Guidance for reading....................................................................................................................... 10
4H
273H
5H
274H
6H
275H
7H
276H
RESEARCH PROBLEM...................................................................................................................... 11
8H
27H
1. SCOPE OF RESEARCH .................................................................................................................. 11
9H
278H
1.1 AREAS OF SIGNIFICANCE ................................................................................................................. 11
1.2 AREAS OF LIMITATIONS................................................................................................................... 11
1.3 EXPECTED OUTCOME OF RESEARCH ................................................................................................ 12
1.4 INTENDED DELIVERABLES ............................................................................................................... 12
1.5 OBJECTIVE OF THE THESIS ............................................................................................................... 12
1.5.1 Relation between problem area and the hypothesis 1 ............................................................ 12
1.5.2 Relation between problem area and the hypothesis 2 ............................................................ 13
1.5.3 Clarification of preliminary concepts..................................................................................... 13
10H
279H
1H
280H
12H
281H
13H
28H
14H
283H
15H
284H
16H
285H
17H
286H
2. METHODOLOGY ............................................................................................................................ 13
18H
287H
2.1 INTRODUCTION ............................................................................................................................... 13
2.2 RESEARCH DESIGN ......................................................................................................................... 13
2.3 DATA COLLECTION TECHNIQUES ..................................................................................................... 15
2.4 RESEARCH REVIEW ......................................................................................................................... 16
2.5 VALIDITY ........................................................................................................................................ 16
2.6 RELIABILITY ................................................................................................................................... 17
2.7 DATA ANALYSIS .............................................................................................................................. 17
2.7.1 Pre-test.................................................................................................................................... 17
2.7.2 Measurement and scaling ....................................................................................................... 18
2.7.3 Types of questions................................................................................................................... 19
2.7.3.1 First open-ended question................................................................................................ 20
2.7.3.2 Second open-ended question ........................................................................................... 20
2.7.3.3 Third open-ended question .............................................................................................. 20
2.7.3.4 Fourth open-ended question ............................................................................................ 20
2.7.4 Tools ....................................................................................................................................... 21
19H
28H
20H
289H
21H
290H
2H
291H
23H
29H
24H
293H
25H
294H
26H
295H
27H
296H
28H
297H
29H
298H
30H
29H
31H
30H
32H
301H
3H
302H
3. KEY FINDINGS FROM THE SURVEY ........................................................................................ 22
34H
30H
3.1 BACKGROUND OF THE RESPONDENTS .............................................................................................. 22
3.2 FREQUENCY DISTRIBUTION ............................................................................................................ 22
3.2.1 EA mature areas ..................................................................................................................... 22
3.2.2 EA immature areas ................................................................................................................. 22
3.3 CROSS-TABULATIONS ..................................................................................................................... 23
3.4 DETERMINING CORRELATION ......................................................................................................... 23
3.4.1 Correlation on first open-ended question............................................................................... 23
3.4.2 Correlation on second open-ended question .......................................................................... 24
35H
304H
36H
305H
37H
306H
38H
307H
39H
308H
40H
309H
41H
310H
42H
31H
Page 2 of 112
3.4.2.1 Economies of Scale.......................................................................................................... 24
3.4.2.2 Synergy ............................................................................................................................ 24
3.4.2.3 Improved citizen service.................................................................................................. 24
3.4.3 Correlation on third open-ended question ............................................................................. 25
3.4.3.1 Lack of resources............................................................................................................. 25
3.4.3.2 Cultural barriers ............................................................................................................... 25
3.4.4 Correlation on fourth open-ended question ........................................................................... 25
3.4.4.1 KL regi............................................................................................................................. 25
3.4.4.2 Between the municipalities.............................................................................................. 26
3.4.5 Other findings ......................................................................................................................... 26
3.5 DRAWING CONCLUSIONS ................................................................................................................ 26
3.6 INTERPRETING RESULTS ................................................................................................................. 27
3.7 SUMMARIZING CONCLUSIONS ......................................................................................................... 28
3.8 MAKING RECOMMENDATIONS ........................................................................................................ 28
43H
312H
4H
31H
45H
314H
46H
315H
47H
316H
48H
317H
49H
318H
50H
319H
51H
320H
52H
321H
53H
32H
54H
32H
5H
324H
56H
325H
4. LITERATURE REVIEW ................................................................................................................. 28
57H
326H
4.1 WORKING TOWARDS A COMMON TERMINOLOGY............................................................................. 28
4.1.1 Introduction ............................................................................................................................ 28
4.1.2 What is enterprise architecture? ............................................................................................ 29
4.2 DEFINING THE ENTERPRISE ............................................................................................................. 32
4.3 DEFINING THE ARCHITECTURE........................................................................................................ 33
4.3.1 Four common viewpoints on architecture .............................................................................. 33
4.3.2 Why Enterprise Architecture? ................................................................................................ 33
4.4 LEGACY OF EA ............................................................................................................................... 35
4.4.1 Relationship to systems analysis and design .......................................................................... 35
4.4.2 Relationship to strategy and business planning ..................................................................... 36
4.4.3 Relationship to component-based and service-oriented architectures................................... 36
4.4.4 Relation to social aspects ....................................................................................................... 36
4.4.5 Development of Systems Development ................................................................................... 36
4.4.6 Development of EA ................................................................................................................. 38
4.4.7 What is Service-Oriented Architecture?................................................................................. 38
4.4.7.1 Benefits of SOA............................................................................................................... 38
4.5 MERGING OF DISCIPLINES ............................................................................................................... 39
4.5.1 SOA and EA ............................................................................................................................ 39
4.5.1.1 The chicken or the egg..................................................................................................... 39
4.5.2 To be or not to be… ................................................................................................................ 40
4.6 PREREQUISITES TO ENTERPRISE ARCHITECTURE.............................................................................. 40
4.6.1 Enterprise Architecture practices........................................................................................... 41
4.6.1.1 Enterprise architecture and business objectives .............................................................. 41
4.6.1.2 Enterprise architecture as a ‘skeleton’............................................................................. 41
4.6.2 Enterprise architecture methodologies................................................................................... 42
4.6.3 The challenges of enterprise architecture .............................................................................. 42
4.7 THE EA PLANNING PROCESS ........................................................................................................... 42
4.7.1 Introduction ............................................................................................................................ 42
4.7.2 Planning an enterprise architecture....................................................................................... 43
4.7.3 Obstacles for successful Enterprise Architecture Planning ................................................... 43
4.7.4 Key Factors to Successful Enterprise Architecture Planning (EAP) ..................................... 45
4.8 EGOVERNMENT MATURITY............................................................................................................. 47
4.8.1 Introduction ............................................................................................................................ 47
58H
327H
59H
328H
60H
329H
61H
30H
62H
31H
63H
32H
64H
3H
65H
34H
6H
35H
67H
36H
68H
37H
69H
38H
70H
39H
71H
340H
72H
341H
73H
342H
74H
34H
75H
34H
76H
345H
7H
346H
78H
347H
79H
348H
80H
349H
81H
350H
82H
351H
83H
352H
84H
35H
85H
354H
86H
35H
87H
356H
8H
357H
89H
90H
358H
359H
Page 3 of 112
4.8.2 Maturity of the State of Denmark ........................................................................................... 47
4.9 EA MATURITY AND MEASUREMENT ............................................................................................... 49
4.10 ARCHITECTURE FRAMEWORKS ..................................................................................................... 50
3
4.10.1 The EA Cube framework ..................................................................................................... 52
4.10.2 The EA Toolkit IT Framework.............................................................................................. 53
91H
360H
92H
361H
93H
362H
94H
36H
95H
364H
5. DESCRIPTION OF THE CURRENT STATE............................................................................... 56
96H
365H
5.1 INTRODUCTION ............................................................................................................................... 56
5.2 BUSINESS STRATEGY DOCUMENTS .................................................................................................. 56
5.2.1 Vision of the structure reform................................................................................................. 56
5.2.2 Goals....................................................................................................................................... 56
5.2.2.1 Strategy for digital strategy for the municipalities28F ........................................................ 56
5.3 THE HISTORY OF EA IN DENMARK LTD. ......................................................................................... 57
5.3.1 Recommendations ................................................................................................................... 57
5.3.2 Joint Enterprise Architecture Framework.............................................................................. 57
5.3.3 Principles................................................................................................................................ 58
5.3.4 Structure ................................................................................................................................. 59
5.3.5 Guidance................................................................................................................................. 60
5.4 THE BUSINESS DRIVERS ................................................................................................................... 60
5.4.1 Key constraints ....................................................................................................................... 60
5.4.2 The six W’s.............................................................................................................................. 60
5.4.2.1 Who?................................................................................................................................ 60
5.4.2.2 What?............................................................................................................................... 67
5.4.2.4 When? .............................................................................................................................. 69
5.4.2.5 How?................................................................................................................................ 69
5.4.2.6 Why?................................................................................................................................ 75
5.4.2.7 Where?............................................................................................................................. 76
97H
36H
98H
367H
9H
368H
10H
369H
10H
370H
102H
371H
103H
372H
104H
37H
105H
374H
106H
375H
107H
376H
108H
37H
109H
378H
10H
379H
1H
380H
12H
381H
13H
382H
14H
38H
15H
384H
16H
385H
6. ANALYSIS OF THE CURRENT STATE ...................................................................................... 77
17H
386H
6.1 INTRODUCTION ............................................................................................................................... 77
6.2 STRESS POINTS/RISKS ...................................................................................................................... 77
6.3 STRENGTHS AND WEAKNESSES ....................................................................................................... 77
6.3.1 Strengths ................................................................................................................................. 77
6.3.2 Weaknesses ............................................................................................................................. 77
6.4 CHALLENGES .................................................................................................................................. 78
6.5 ENVIRONMENTAL FACTORS............................................................................................................. 79
6.6 GROWTH/COST CONTAINMENT OPPORTUNITIES............................................................................... 79
18H
387H
19H
38H
120H
389H
12H
390H
12H
391H
123H
392H
124H
39H
125H
394H
7. DESCRIPTION OF THE TARGET STATE.................................................................................. 80
126H
395H
7.1 INTRODUCTION ............................................................................................................................... 80
127H
396H
8. ANALYSIS OF THE TARGET STATE ......................................................................................... 81
128H
397H
8.1 INTRODUCTION ............................................................................................................................... 81
8.2 INTEGRATION .................................................................................................................................. 83
129H
398H
130H
39H
9. EA MANAGEMENT PROGRAM .................................................................................................. 84
13H
40H
9.1 INTRODUCTION ............................................................................................................................... 84
132H
401H
10. CONCLUSION, REFLECTIONS, PERSPECTIVES ................................................................. 87
13H
402H
Page 4 of 112
10.1 CONCLUSION................................................................................................................................. 87
10.2 REFLECTIONS ................................................................................................................................ 87
10.3 PERSPECTIVES ............................................................................................................................... 88
134H
403H
135H
40H
136H
405H
REFERENCES ...................................................................................................................................... 90
137H
406H
LITERATURE ......................................................................................................................................... 90
INTERVIEWS .......................................................................................................................................... 96
138H
407H
139H
408H
APPENDIX............................................................................................................................................. 97
140H
409H
APPENDIX 1: THE STUDY SURVEY REPORT .......................................................................................... 97
APPENDIX 2: ZACHMAN FRAMEWORK .................................................................................................. 98
APPENDIX 3: BERNARD’S EA3 CUBE .................................................................................................... 99
APPENDIX 4: FRAMEWORK FOR COMMUNITY MERGENCE BY FLEMMING HALD AND BO KRISTENSEN
........................................................................................................................................................... 100
APPENDIX 5: CHALLENGES FACING THE PUBLIC SECTOR IN THE FUTURE IN DENMARK ....................... 101
APPENDIX 6: CITIZEN SURVEY MADE BY COMPUTERWORLD AND USERNEEDS, DECEMBER 2006 ...... 102
APPENDIX 7: MAP OF THE “NEW DENMARK” AFTER THE STRUCTURE REFORMATION ......................... 104
APPENDIX 8: ENTERPRISE ARCHITECTURE VALUE MEASUREMENT METHODS FRAMEWORK ............. 105
APPENDIX 9: THE RESPONDENTS......................................................................................................... 106
APPENDIX 10: INTERNET QUESTIONNAIRE (HTTP:WWW.FLEMMINGHALD.DK/EA)............................... 107
GLOSSARY .......................................................................................................................................... 112
General terms ................................................................................................................................ 112
Danish terms .................................................................................................................................. 112
14H
410H
142H
41H
143H
412H
14H
413H
145H
41H
146H
415H
147H
416H
148H
417H
149H
418H
150H
419H
15H
420H
152H
421H
153H
42H
Page 5 of 112
Abstract
Enterprise Architecture – often referred to as business oriented use of IT or simply put EA – has been
an issue within the public domain at State level for some time now. It is often used in conjunction with
another popular acronym, SOA, Service-Oriented Architecture. The intentions of EA in public
Denmark has been formulated through a white book and the Ministry of Finances are talking about the
strategic use of IT in the public domain. This thesis sets out by analyzing the maturity of the
municipalities and the State of this matter. It does so by describing the EA activities within the public
domain. These are described based on a comprehensive survey made within the field targeted towards
the municipal CIO’s.
I reach the conclusion that the municipalities not are at a mature state in regard to the awareness,
propagation and use of enterprise architecture. I reach the conclusion that the State is however more
mature in this area. But there is something missing in the way the public is structured in order to move
Denmark upward the maturity ladder and to support, coordinate and communicate EA efforts
throughout the entire public sector.
The answer lies in the organizational structure. From my research I propose the establishment of an
Enterprise Architecture Committee as a central actor in carrying out all EA initiatives throughout public
Denmark. This newly formed committee will be in close connection with already established and well
functioning councils and committees. Representatives of the most important actors will be part of this
committee thus carrying weight and influence behind its initiatives and suggestions.
Page 6 of 112
Introduction
The Danish Parliament announced just before the summer holidays in 2005 the law package dealing
with the task- and structure reformation. This law was passed by June 16, 2005 and will be carried out
by January 1, 2007. It suggests the merging of municipalities in Denmark as well as replacing the
counties with regions. Another consequence is that many tasks will be reallocated within the public
sector in Denmark.
The municipalities have responded much differently to the challenges which inevitably will follow.
Some municipalities have been visionary and have seen this as an opportunity to also restructure the IT
infrastructure and the use thereof and have taken steps toward implementing IT as part of their business
strategy. Other municipalities have merely floated along the main stream focusing only on “safe use of
IT” with no vision or innovation. We still see each municipality doing what they want to do and the socalled silos are still present in the different municipalities. Even though steps have been taking to ensure
standards, interoperability and openness in the public sector we are far away from seeing this realized.
"The significant problems we face cannot be solved by the same level of thinking that
created them."
- Albert Einstein
The focus needs to be higher – on enterprise architecture – the organizing logic for core business
processes and IT infrastructure reflecting the standardization and integration of a company's operating
model. “Therefore enterprise architecture boils down to these two concepts: business process
integration and business process standardization. In short, enterprise architecture is not an IT issue - it's
a business issue" (Weill & Ross, 2006).
The purpose of this thesis is to describe the EA activities in Denmark as well as finding out at what
level the municipalities and the State find themselves in, in relation to enterprise architecture, and
finally what will the next step be for these governmental bodies embracing enterprise architecture.
Page 7 of 112
Background
The originally starting point for the present study rests on previous research, where problems perceived
within Slagelse municipality, a city merging from four totally different cities into one single city, seem
to lack an overall IT strategy. Between the different municipalities there was a need, but no consisting
method, for information exchange between the municipalities and its citizens. I set out to analyze why
this was so, and found a gap between the overall strategy and the use of IT. At that time Bo Kristensen
and I found a method to bridge this gap by suggesting a best practice EA framework for merging
municipalities (Kristensen & Hald, 2005). Having noticed this problem in other municipalities as well, I
will now set out to describe and analyze the awareness and use of EA across the Danish municipalities.
This thesis presents the results of my research within this field.
Intended audience
In order to make this thesis as widely accessible as possible it is written in English. Thus it is written
with an international audience in mind. To this end, a glossary of the most common Danish terms can
be found at the very end of the thesis. The result of my research is not limited to a so-called Danish
model alone, but could universally be adopted by other countries as well with a similar democratic
public structure as can be found in Denmark.
Structure of the thesis
In order to gain a better overview of the structure of this thesis, I have chosen to show this in a
graphical view as can be seen from figure 1. This figure indicates eight main stages. The small number
in each frame indicates the subject stage.
At “ground zero” or stage zero I will pose my research problem as a question with hypothesis. The
hypothesis posed is based on prior observations of the subject and will provide the basis for later
empirical testing. In stage one, the scope of research will be described, and here I will describe areas of
significance and limitations in relation to my research. I will also include the outcome expected of my
research as well as the intended deliverables. In stage two I will describe the chosen methodology, or
W
Scope of
research
Research problem
\
Description
of current state
Analysis of
current state
Y
X
Methodology
]
Description of
target state
^
Key findings
from survey
Analysis of
target state
Z
_
Literature
Review
[
`
EA management
program
Conclusions, a
reflections,
perspectives
Figure 1. Structure of the thesis.
Page 8 of 112
the way in which I systematically will address my research problem. This description is two-fold: 1) a
description of the literature review in connection to methodology and 2) a description of the methods
applied for collecting and analyzing data for my research. Stage three contains the key findings from
the survey study report. At this stage I expect to find out the general EA maturity level of the
municipalities. Stage four, literature review, constitutes the main theoretically research portion of the
thesis. From this research, a common terminology on a number of aspects of EA is decided upon.
Among other things an EA framework will be selected for the further work. This stage will also be the
input to the development of the Internet based questionnaire – e.g. which EA areas should I include in
the survey in order to fully address my research problem. In stage five, the description of the current
state of EA in Denmark will be described. This entails the collection of key facts about the business:
just the facts…and nothing but the facts. This description of facts will serve as introduction to stage six,
analysis of the current state of EA. This stage will analyze the problems and challenges faced by the
public sector seen from a number of different criteria prescribed by the framework selected in stage
four. A great deal of the content of stages five and six, will originate from the developed study survey
report. Once the baseline description of where the public sector is today is completed, I will focus on
where it wants to go. Stage seven, description of the target state, basically describes this, and where the
business will be if the problems and challenges are resolved. Another way of looking at this stage is
seeing the achievement of missions and goals. Stages five and six will be input to stage seven. Stage
eight, analysis of target state, is about comparing the ‘analysis of current state’ with the ‘description of
target state’ and then I will identify any gaps and opportunities. All this gives us a set of target business
opportunities to direct and drive the IT architecture effort. Having accomplished this, stage nine will
describe an EA management program. This is often referred to as a transformation program. What this
basically means is that it suggests how to move from current state to desired target state taking into
consideration an ever changing environment. A summary of this stage will constitute “The next step…”
in the study survey report. Finally, in stage ten, I will conclude on the research problem from stage one.
I will reflect on the process I have been through during the making of this thesis and the study survey
report. At the end of stage ten, I will attempt a bird’s eye view and go beyond EA and provide a
perspective on alternative solutions, theories or other practices that might be more suitable in the
pursuit of an optimal digital public sector in answer to the research problem.
Relationship between the two reports
This thesis is made up of two reports: the background report and the study survey report. On one hand,
the reports are separate in the sense that they focus on two different target groups, and on the other hand
they can be considered as one (as is the case with this thesis) in the sense that they provide useful
information for each other, thus creating one whole report. Figure 2 illustrates the structure of the
reports as well as their inter-relationship. For the sake of not violating any formal rules of CBS 1 the
study survey report will be placed as appendix 1 2.
0F0F
1F1F
I have two different target groups in mind with each report. The background report is targeted towards
my supervisor and the external examiner as well as those who would like background information of
the structure and content of the study survey report. The study survey report is first and foremost
targeted towards the municipalities and secondly, towards foreign authorities or agencies with an
interest in public EA.
1
2
CBS = Copenhagen Business School, http://www.cbs.dk
See appendix 1
Page 9 of 112
Study survey report
Background report
1. Research problem
2. Scope of research
3. Methodology
4. Key findings from survey
5. Literature review
6. Description of current state
7. Analysis of current state
8. Description of target state
9. Analysis of target state
10. EA management program
11. Conclusions, reflections,
perspectives
X
Y
Z
[
1.
2.
3.
4.
Introduction
EA key results
EA in the public sector
EA motivation, goals and
barriers
5. EA measurement
6. EA process
7. EA framework
8. EA tools
9. EA governance
10. EA assets
11. The next step…
Figure 2. The relationship between the two reports
Their ongoing inter-relationship is based on four ways of providing input to the other (note the arrows
of Figure 2). The first arrow indicates the methodology chapter will provide the necessary input for me
to produce a valid and reliable survey instrument. This helps me to know how to formulate the
questions, decide on the length of the questionnaire, whom to send out to, when to send out, i.e. all
about the survey instrument itself. The second arrow will provide me with the necessary professional
knowledge to identify which areas of EA should be addressed in the survey in order to fully address the
research problem, i.e. all about which content to put into the instrument. The third arrows going from
the study survey report to the background report provide vital input to the main chapters of the
background report. The fourth arrow represents an abridged version of the EA management program
transferred to the study survey report suggesting the municipalities what to do next, the so-called “Next
Step”.
Guidance for reading
I suggest my supervisor and the external examiner will read the background report first for gaining an
understanding of the background of the structure and content of the survey instrument. The municipalities and State actors will most likely only be interested in the study survey report, but can gain further
knowledge and insight by studying this background report.
Page 10 of 112
Research Problem
Overall question
From the above mentioned purpose of the thesis I have formulated the overall question:
What Enterprise Architecture activities are currently applied within the public domain of
the municipalities and the State?
Hypotheses
1. The awareness, propagation and use of Enterprise Architecture in the Danish municipalities are
immature.
2. The awareness, propagation and use of Enterprise Architecture at the national level in Denmark
are mature.
These hypotheses are based on observations from previous research on the subject of Enterprise
Architecture within municipalities merging. It is the aim of this thesis to either validate or falsify this
hypothesis.
1. Scope of research
1.1 Areas of significance
In order to validate or falsify the hypotheses, EA will be addressed as a discipline with a primary focus
on the interrelationship of the municipalities and the relationship between the state and the
municipalities in serving the citizens. The view of research is thus mainly of a horizontal nature
spanning across the municipalities.
Vast information both on the theory part as well as the subject of the merging municipalities exist. In
the theory part, I have emphasized two criteria in the selection of my literature: 1) those who favor
practical approaches and 2) those generally well known EA advocates others build their theories on in
the EA field (see literature review for more detail). For the subject part, I have especially emphasized
secondary sources. This entails 1) previous survey and 2) previous research on the matter.
1.2 Areas of limitations
It goes beyond the scope of this thesis to deal with the tasks and structure of the new regions, wherefore
I will not describe or analyze the regions at all. The reason for this is that I believe they play an inferior
role compared to the municipalities and the State in the new structure reform. As far as municipal tasks
goes, I will not look upon the internal administrative tasks such as salary, staff, logistics, procurement
etc. just as I will not deal with the subject of companies in this thesis. The main focus is the citizens, the
national authority tasks and service tasks within the municipalities and the State of Denmark (see
chapter 5.4.2.2 for further detail).
It is likewise outside of the scope, to make a thorough research comparison with other countries’
municipalities to see what Denmark can learn from these. I will however touch lightly upon this matter
in referring to relevant research results produced by the US at the end of the thesis. Even though this
study is intended for an international audience, the scope of context of my own research is national, and
Page 11 of 112
deals exclusively with the State of Denmark and its municipalities. I will only lightly touch base on the
topic of Service-Oriented Architecture (SOA). I do believe however that this is a most essential topic
wherefore it has been included in relevant places in this thesis where it provides insight to the study
question at hand. Another reason for including SOA is that programming simply is entering the era of
services, and services are a realization of SOA. There is simply no way around it these days.
1.3 Expected outcome of research
The expected outcome of my research will be a proposal of an overall transformation plan for the public
sector to use when moving from a current view to a future view of their EA program. There will be
focus on the municipalities. In order to substantiate this plan and as mentioned earlier, two reports will
be produced, a background report and a study survey report.
1.4 Intended deliverables
I intend to deliver a study survey report documenting the propagation of EA in public Denmark as well
as a background report forming the basis of the development of the study survey report. This
background report also documents and analyzes the findings from the study survey report and describes
and analyzes the current and future state of public EA in Denmark. Finally, I will seek to lay out an EA
management plan which suggests where the public sector should go from here; this is called “The next
step…” and can be found in the Study Survey Report.
1.5 Objective of the thesis
The objective of this study is to obtain an overview of current Enterprise Architecture activities in the
Danish municipalities and in the State. This overview will form a picture of the current EA state, and
will serve as input to answer the study’s main question:
What Enterprise Architecture activities are currently applied within the public domain
of the municipalities and the State?
Figure 3. The main question of the study
I do not expect to gain a perfect knowledge of this picture from the study, but I do expect sufficient insight based on my research in order to make an intelligent decision as to validate or falsify the
hypotheses in question:
1. The awareness, propagation and use of Enterprise Architecture in the Danish
municipalities are immature.
2. The awareness, propagation and use of Enterprise Architecture at the national level
in Denmark are mature.
Figure 4. Hypotheses of the study
1.5.1 Relation between problem area and the hypothesis 1
In validating and/or falsifying the two hypotheses, I will indirectly address the overall question of the
problem area. In case of validation of the first hypothesis, a new proposed EA management program on
the matter will be developed and recommended from the synthesis the primary research (the study
Page 12 of 112
survey report and description/analysis of the current/target state) and the secondary research (literature
review) is expected to form. This management program could be considered a best practice and will
form the next step for the public sector to take in order to move closer to public EA in Denmark. This
will not only answer the overall question of the problem area, but also provide a solution for moving on
to the next level. In case of falsification of the hypotheses, the results will be re-analyzed and again the
next steps for the public sector is described, now only at a higher, more mature level. Either way the
hypotheses will assist in answering the main question of the study.
1.5.2 Relation between problem area and the hypothesis 2
In case of validation of the second hypothesis, the results will be collected again and the next more
mature steps for the public sector will be described. In case of falsification, a new proposed EA
management program on the matter will be developed and recommended from the synthesis the
primary research (the study survey report and description/analysis of the current/target state) and the
secondary research (literature review) is expected to form.
1.5.3 Clarification of preliminary concepts
Before continuing, I need to clarify the definition of the word ‘mature’ and ‘immature’. The Oxford
dictionary defines mature as ‘fully grown or physically developed; adult’. The Merriam-Webster
dictionary defines it as ‘having attained a final or desired state’. The Encarta dictionary defines
mature as ‘showing qualities gained by development and experience’. I will use the last
definition of mature:
Showing qualities gained by development and experience.
Immature will then be the opposite ‘showing no qualities due to lack of development and
experience’. For practical reasons, I set the EA maturity factors equal to the number of 80% or
more and 20% or less in determining whether or not the municipalities are mature within an
aspect of EA. Everything in-between is semi-mature and cannot be assessed as either or. These
are basic assumptions used throughout the thesis in assisting the validation or falsification of
my hypotheses.
2. Methodology
2.1 Introduction
As stated earlier, this stage deals with the way in which I systematically will address my research problem. Here I will present process areas of two aspects: 1) research design and 2) methods applied for
collecting and analyzing data for my research.
2.2 Research Design
There are two main categories of research design (Field, 2005; Joppe, 2005) namely 1) exploratory
research and 2) conclusive research. Conclusive research can be subdivided into:
1. descriptive research
2. casual research
Page 13 of 112
Each of these types relies on one or more data collection techniques:
1. Primary research
a. Observation techniques
b. Direct communication with subjects, e.g. survey technique, interview or projective
methods
2. Secondary research
a. Literature review
b. Data sources collected for other purposes than the study at hand
Irrespective of the chosen data collection technique, it is critical for me to analyze it for its validity and
reliability. Another critical consideration is the number of subjects to address. Addressing all elements
in the population, i.e. all CIO’s in the municipalities, may be ideal, but not very practical and far too
costly. Instead with careful guidance from my supervisor, I choose a minimum response sample rate
from my survey of 33% of the entire population before closing the survey, thus using the so-called
probability sampling technique.
Exploratory research is often conducted because a problem has not been clearly defined yet or its real
scope is unclear. It is often the first research method to use before any conclusive research is conducted.
Exploratory research either allows the researcher to generate hypotheses to be tested or to test concepts
before being sent out to the market. Exploratory research can be quite informal relying on secondary
research such as review of literature and data or qualitative approaches such as informal discussions
with consumers, competitors, or employees or perhaps more formal approaches through in-depth
interviews, focus groups, case studies or pilot studies.
Descriptive research – sometimes referred to as statistical research – provides data about the population
or universe being studied. In its nature it is limited to “only” describe “who, what, when, where and
how” of a situation, not what caused it. Therefore this is the preferred method that is as factual and
accurate as possible. It provides the number of times something occurs – frequency – thus ideal for
statistical calculations. The two most commonly used types of descriptive research designs are:
1. Observation
2. Surveys
Both the observation technique and surveys are primary methods of collecting data. When a particular
behavior needs to be recorded observation is often the chosen type of research design. Observation is
not relevant for my study. When many different types of information needs to be collected, including
attitudinal, motivational, behavioral and perspective aspects a questionnaire is often used. It is very
popular because it allows for standardization and uniformity both in the questions asked and in the
method of approaching the subjects making it much easier to compare and correlate answers by the
respondent group. It also ensures higher reliability than many other techniques.
There are of course both advantages and disadvantages for conducting such a survey. The most obvious
advantages are that it provides an efficient and accurate way of determining information about a given
population. In my case this is the municipal CIO’s. Results can also be provided quickly and they are
relatively inexpensive.
Page 14 of 112
Having said this, there are of course also disadvantages. Probably the greatest is that the respondent
knows he or she is being watched and this can lead to invalid responses inasmuch as the respondent
may want to impress (e.g. by giving the impression that they are better or know more about EA than
what is real) or please (e.g. by giving the kind of response they believe the researcher is looking for) the
researcher. This is known as response error or bias.
The willingness or ability can also cause a problem. If the questions are considered sensitive or intrusive this could keep many away from responding. I have made it very clear that my survey is
anonymous, thus hoping all will be willing to “take the risk” in responding to my questions. If the
people who refuse really are different from the rest, this is known as non-response error or bias.
If an interview is held the interviewer can inadvertently influence the respondent by the way he poses
the questions, stresses certain words or his body language. Even facial expressions or the cloths he
wears can influence the respondent. This is known as interviewer-error or bias.
There are many factors that can influence the response rate:
• The chosen method
• The length of the questionnaire
• The type of questions
• The time of day or place
• The relevancy of the questions compared to the respondents position
There are three types of surveys:
•
•
•
Telephone
Self-administered
Interview
I choose to conduct a survey as my preferred descriptive research method type 3. The reason for this is
due to the high number of elements in the population of my universe of discourse: 98 municipalities.
Among other things, I expect to find out from as many as possible – a minimum 33% – what the
knowledge is of Enterprise Architecture in the municipalities, how many uses it, and how much they
use it etc. All these questions fall into the category of descriptive research, and the best way to aim as
many as possible is through conducting a self-administered survey, despite of the disadvantages herein.
I will therefore conduct an Internet based survey in order to find out “what is going on with EA” in the
municipalities of Denmark.
2F2F
I have not touched upon casual research yet. This is another branch of conclusive research where you
try to establish a so-called cause-and-effect relationship between variables. This type of research is
often very complex and the underlying methods are experimentation and/or simulation. The researcher
can never be sure though if there are no other factors influencing the casual relationship.
2.3 Data collection techniques
As mentioned earlier, when doing primary research, data is collected for the study at hand. This can be
obtained by having the researcher observing the subject being studied, or by communicating directly or
3
See http://www.flemminghald.dk/ea or Appendix 10
Page 15 of 112
indirectly with the subject. Direct communication techniques include qualitative research techniques
such as in-depth interview, focus groups and projective techniques, while quantitative techniques
include techniques such as telephone, self-administered and interview surveys.
2.4 Research review
Knowledge is – as science – cumulative. Therefore before one of the above-mentioned techniques are
attempted it is important to commence all research with a review of the related literature or research at
hand, and to determine whether any data already exist that can be brought to solve the research problem
at hand. This is often referred to as secondary research. Each study of an earlier work will provide the
basis of the future work done by others.
As far as I know from my present and previous research, there is no description and analysis of EA
across the municipalities compared to the State view. Therefore this will be new knowledge brought
forth, which other researchers hopefully can benefit from. There are however adjacent research with
indirect influence to my study question. These comprise “Analysis of Enterprise Architecture in
connection with the merging of municipalities” (Bo Kristensen et al, 2005), “An International
Enterprise Architecture survey, trends in governmental Enterprise Architecture on a national level”
(Peter Engelund Christiansen, 2006) and “Service Oriented Enterprise Architecture” (Rasmus Knippel,
2005). I will include relevant parts of this previous research in my thesis when relevant.
I will not list the all the number of persons quoted in my literature review, but instead present the
criteria on which I have based my selection. Having read a great number of books, papers, articles,
reviews and commentaries from the enterprise engineering community, I have especially emphasized
the following criteria when selecting my literature: 1) those who favor practical approaches (NIST
1989, Armour et al. 1991a, Hasselbring 2000, The Open Group 2002, Buchanan and Soley, 2002, and
Heffner 2002) and, 2) those generally well known EA advocates others build their theories on in the EA
field such as Zachman (1987), Spewak (1992) and the Open Group (1995).
2.5 Validity
Validity determines whether the research really measures that which it was intended to measure or in
other words: how truthful are the results? Does the research instrument allow me to hit “the bull’s eye”
of my research object? Starting with the research question:
Can I actually answer this overall research question with the research instrument selected? Are the
respondents truly a representation of the entire population? What if a certain type of CIO is not reached
through the survey? Setting a high percentage of respondents (33%) diminish the risk of not capturing
all types of the respondents’ views. Having this in mind, I believe I can answer the overall question
with a database-driven questionnaire that asks for general input on a number of EA aspects
substantiated through personal interviews and relevant literature. In order to identify which areas to
cover and the wording of the questions I want to review literature and other research projects, so I will
be able to produce a more sufficiently valid questionnaire that can more fully help in answering the
research question at hand.
Page 16 of 112
I have a general idea that early in the morning is the best time for me to send out invitations for
participating in my survey to the CIO’s. I plan on having the survey run for three weeks and have the
invitations sent out Monday of the first week, Tuesday of the second week and Wednesday of the third
week in order to reach the “magic 33%” respondents percentage thus securing external validity.
I will ask a number of people to help me pre-test the instrument. Some of them know little and some
know much about the subject matter; and can help me ensure the questions are clearly worded and
easily understood. I will look at other research and its wording in this connection. This I find important
when measuring more subjective concepts such as attitudes and motivations of which I have a few in
my questionnaire. I will consider asking the same question in different ways or repeat it at a later stage
in the questionnaire in order to test for consistency in the responses. This will confirm criterion validity.
This I will only do once or twice though, due to the estimated length of the questionnaire.
Probing for attitudes usually requires a series of questions that are similar, but not the same. This
battery of questions should be answered consistently by the respondent. If it is, the scale items have
high internal validity. I will therefore put most of these ‘attitude’ questions close together. All this will
increase the validity of my research instrument.
2.6 Reliability
The extent to which results are consistent over time and an accurate representation of the total
population under study is referred to as reliability. This means that if the results of the study can be
reproduced with a similar methodology, then the research instrument is considered to be reliable.
If questions can be misunderstood, and therefore is answered differently by respondents, you have low
reliability. One way of finding out if this is the case is by running a test-retest, where a respondent
would be asked to answer the survey at two different times. This also gives an indicator of the stability
of the measurement. If I have a stable measure, then the results should be similar. A high degree of
stability indicates a high degree of reliability, since the results are reproduced. The disadvantage of this
method is that external factors such as change in attitude can influence the respondents answer and
these factors are very difficult to detect. I will not ask my respondents to respond to my questionnaire
twice, since first of all I do not have much time at hand, and secondly, the CIO’s probably have less
time than I do, being busy with merging activities.
Usually reliability is a function of validity. This means that validity often presupposes reliability. The
reverse is not always the case however. I can end up proving the research instrument’s repeatability and
internal consistency, and therefore reliability, while the instrument itself may not be valid, meaning that
it does not measure what the research proposed to determine.
2.7 Data analysis
2.7.1 Pre-test
The main reason for pre-testing will be to test three in particular areas involved in writing the questions:
•
•
•
Determining the question content, scope and purpose
Choosing the response format that I should use for collecting information from the respondent
Figuring out how to word the question to get at the issue of interest
Page 17 of 112
So after having developed the instrument, I will enter my three-loop pre-test phase. In the first phase, I
will ask a few acquaintances who know very little about the topic of study, merely to make sure the
sentences are readable. In the next pre-test phase, I will invite people in the target group (two CIO’s,
one IT strategy person, and one IT-architect) and the chairman for KIT@ (The Association of
Municipal CIO’s) to pre-test the instrument in order to ensure its validity and reliability. This phase two
will be repeated in phase three as an iterative process.
2.7.2 Measurement and scaling
The first question I will need to ask myself is: “What is to be measured?” I wish to measure the
awareness, propagation and use of Enterprise Architecture in the Danish municipalities in order to
identify an EA maturity level. The survey instrument will not address the national level of EA maturity
since this will be dealt with later in chapter 4.8.
I would define the maturity mostly in objective closed “either-or” questions; I will however also
measure a few key areas with attitudinal questions in particular in relation to the common public citizen
portal and the possibility of a future joint municipal IT co-operation. In conclusive research, where I
rely on quantitative techniques, the objective is to express in numeric terms the difference in responses.
Hence, a scale is used to represent the item being measured in the spectrum of possibilities. There are
four basic types of scales:
• Nominal
• Ordinal
• Interval
• Ratio
Nominal scale indicates the use of a label, e.g. “1” for having an IT-strategy and “2” for not having an
IT-strategy.
Ordinal scale indicates a classification of items to show if they have more or less of a characteristic, e.g.
how would you rate the joint citizen portal?
Excellent O Very Good O Good O Fair O Poor O
One of the problems with ordinal scales however is the uncertainty attached to the responses. Does the
‘Good’ response by one, really mean ‘Excellent’ by another? Understanding ‘the language’ of the
population is here very important. Likert’s ordinal scales are typically a question posing a statement and
ask the respondent whether they Strongly Agree – Agree – Undecided – Disagree or Strongly Disagree.
His scale is commonly used in attitudinal measurements.
Interval scales are similar to the ordinal except for the distance between the adjacent points on the scale
are equal, e.g.
How much of your business architecture are kept up-to-date? 0%-20% O 20%-40% O 40%60% O 60%-80% O 80%-100% O
Finally the ratio scale is like the interval scale, except it has a true zero scale. For example height,
weight etc. have a true zero. It makes sense to say that 2 meter is twice as large as 1 meter. The ratio
scale is the most sophisticated and incorporates all of the other three scale types.
Page 18 of 112
The most common measurement methods are:
• The mean
• The frequency
• The mode
• The percentile
• The median
• The range
The mean indicates an average number. The frequency indicates the number an item appears in the
whole distribution. The mode refers to the most common value in a set of observations. The percentile
indicates that when data are skewed and off from a standard deviation, e.g. if the 85% percentile of
household income is $60,000, then 85% of households have incomes of $60,000 or less, while the top
15% of households have incomes of $60,000 or more. The median is the most famous percentile. It is
called the 50th percentile splitting the data in half – half of the data are above the median; half of the
data are below the median. The range simply indicates the highest value minus the lowest value.
Mapping these measurement methods to the various types of scales we get Table 1.
The nominal
(using labels)
The mean
The frequency
The mode
The percentile
The median
The range
X
X
The ordinal
The interval
The ratio
(using classification)
(20%-40%)
(same as interval with true zero)
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Table 1. Comparison of measurement method and types of scales. Source: Own contribution
In order for me to answer my hypotheses most of the questions will be on a YES/NO nominal scale as it
has no order or distance between them. I will for the greater part need to determine “How many” or
“How much”-type of questions. This is the frequency measurement and belongs to a nominal scale. It is
vital that the response categories include all possible responses. To be exhaustive in the response
categories, I will have to include ‘other’ and/or ‘don’t know’ as an option. I do not find Likert’s ordinal
type of scale relevant for my study! Instead I do find the interval scale extremely relevant in seeing the
degree of EA aspects used by the municipalities. To sum up I use the interval and nominal scales in my
study survey.
2.7.3 Types of questions
In general there are two types of questions: open-ended (open) questions and closed-ended (closed)
questions. The former are required to respond with their own words, whereas the latter consists of a
number of alternative responses. Closed questions are much easier to interpret since they are
standardized and can be analyzed analytically. These types of questions are also quicker to complete for
the respondent. The disadvantage is that they are more difficult to write since all possible responses
must be thought of beforehand. Ultimately, the respondent is being asked to select the response closest
to his/her own point of view.
Page 19 of 112
Open-ended questions are questions that encourage people to talk about whatever is important to them.
Referring to students, The Johns Hopkins University in Baltimore suggest that ”Open-ended questions
should lead students to think analytically and critically. Ultimately, a good open-ended question should
stir discussion and debate in the classroom sparking enthusiasm and energy in your students 4.” This is
exactly what I hope my four open-ended (attitudinal) questions in my study survey will give rise to.
3F3F
2.7.3.1 First open-ended question
“One of the purposes of the structure- and task reform is for the municipality to be the primary entrance
of the citizens’ contact with the public in the future. Yet KL is doing a joint public citizen portal at
www.borger.dk. What do you think about that?”
154H
2.7.3.2 Second open-ended question
“What could be your municipality’s primary motivation for participating in a joint municipal IT cooperation concerning solution of common tasks after January 1, 2007?”
2.7.3.3 Third open-ended question
“What do you see as the greatest obstacle in obtaining this joint IT co-operation?”
2.7.3.4 Fourth open-ended question
”How do you assess the optimal organisation of common solution of common tasks in a joint municipal
IT co-operation?”
The first open-ended question is purposely written as a leading question with two extreme choices: 1)
www.borger.dk is superflous, 2) www.borger.dk is indespensable with the escape option of 3) No
opinion. The reason for these two extremes are that I want the CIO’s to take a stand, not just cross off
an in-between option such as ’Fairly good’ or ’Relevant’. This does not tell much. And then I want
them to substantiate their answer by providing a ’Please-give-a-reason-for-your-reply’ text box for
them.
15H
156H
The second open-ended question was at first worded as a multiple-choice question, but was later
changed to a semi-open question with the word ’primary’ added to the question and a fixed response list
consisting of 13 choices and an escape option ’No matter what I will not participate” to choose from.
This was done in order to have the municipal CIO’s taking a stand.
The third open-ended question underwent similar ”surgery” as the second open-ended question. Only
this time the word ’greatest’ was added as well as a list of six choices and the escape option ’Other’. If
’Other’ was chosen, I want them to specify, hence the ’Specify’ textbox.
The fourth open-ended question is not quite as complex in its response options. Only three options,
including an ‘Other’, are possible. And again, if ‘Other’ is chosen, another ‘Specify’ textbox appears.
The reason for producing these long pre-determined lists are it is much easier to make statistic material
on selections instead of extracting key words from sentences. The risk is that I do not cover all possible
responses, wherefore it will take a long time and analysis to produce this list.
Even though open-ended questions certainly have its justification, I will attempt to produce a structured
questionnaire with as few open-ended questions as possible. The majority of the questions will most
4
http://www.jhu.edu/gifted/teaching/strategies/analysis/openendedquestions.htm
Page 20 of 112
likely be closed questions of quantitative nature, since I will need to produce statistical material in order
to more fully answer the research question with its attached hypotheses. I will group my questions into
categories that are meaningful. A part of the literature review will serve as input in determining these
categories (see figure 2).
Once I receive a minimum of 33% responses, the data will need to be ‘cleaned’. This means ensuring
the data is entered correctly and correcting any errors. I will check for accuracy in a couple of ways:
• Double entry: data has been entered twice and any discrepancies are verified against the original
questionnaire
• Scanning for errors in values based on the original questionnaire, e.g. if only four values are
possible there should not be a value ‘5’.
Then the data will be ready for tabulation and statistical analysis. I will in this part do the following:
• Describe the background of the respondents based on demographic information;
• Describe the responses made to each of the questions;
• Compare the behavior of various demographic categories to one another to see if the differences
are meaningful or simply due to chance;
• Determine if there is a relationship between two characteristics as described; and
• Predict whether one or more characteristic can explain the difference that occurs in another.
The focus will not however be on the respondents, but rather on the direct response made to each of the
questions as well as various types of cross references in order to identify any correlation. As stated
earlier I will describe the outcome mainly as percentages in a so-called frequency distribution. This will
also be done in describing the responses made to each of the questions. In cases of “typical” or
“average” response this is sometimes referred to as central tendency.
In order to compare the behavior of various demographic categories to one another to see if the
differences are meaningful or simply due to chance, I am really determining the statistical significance
by tabulating two or more variables against each other in a cross-tabulation (e.g. "There is clear
evidence of a relationship between gender and attendance at cultural venues. Attendance by women was
statistically higher than men’s").
157H
158H
In determining a relationship between two characteristics I am estimating a correlation. Finally, in
trying to predict whether one or more characteristic can explain the difference that occurs in another, I
could ask a question such as “Is the geographical area of the municipality linked to the maturity of
EA?”
2.7.4 Tools
The study survey report will be produced in this manner: I will use SQL to extract the outcome. Then I
will transfer these data to Excel where charts will be produced. These I will export to Illustrator to
produce quality vector graphics and subsequently import these into InDesign for the graphical layout.
Page 21 of 112
3. Key findings from the survey
3.1 Background of the respondents
Normally one would describe the respondents based on their income, habits, age, gender, education and
so forth, but these are most relevant in consumer surveys in order to improve the marketing of
products/services. I want to find out what the EA activities within the public domain are. In answering
this question, I do not find it relevant to ask for this normal demographic variable input from the
respondents, as I believe they are mutually independent of the study of the EA activities at hand.
Therefore the only demographic variables 5 included in the questionnaire are
• Job function
• Geographic location (inferred from the name of municipality).
• Type of municipality they belong to (e.g. merging municipalities).
4F4F
The majority of the respondents (58%) lives on Zealand; are CIO’s (88%) and belongs to a merging
municipality (52%).
3.2 Frequency Distribution
The general collection of the frequency distribution of single survey questions can be seen in the
produced study survey report. Having the hypothesis in mind in which I state that the awareness,
propagation and use of Enterprise Architecture in the Danish municipalities are immature, I will present
the areas of which I find the municipalities immature within this type of distribution. As mentioned
earlier the 20%/80% assessment indicator of maturity will be used to establish this fact. This is not an
absolute truth, since I am aware of the general uncertainty connected to all statistical data, but it gives
us a rather good indicator of what is likely to be ‘the truth’.
3.2.1 EA mature areas
Given the assessment indicator, the municipalities are considered mature when it comes to having an IT
strategy (94%). The same goes for the EA function to support the strategic management level (94%).
With respect to organizational behavior, most municipalities are used to having IT staff working in
overlapping groups, i.e. where one employee is placed in several working projects (82%). Most CIO’s
find themselves in municipalities demanding the use of IT tools (87%). As far as having an attitude of
being responsible, most CIO’s agree that a future joint municipal EA program should be governed
through current practice (88%).
3.2.2 EA immature areas
I will also now use the 20%/80% assessment indicator to establish any immaturity. The number of
responses is generally very poor when inquired about an EA framework. The most immature area is
revealed in the lack of a published EA framework (87%). Without an EA framework it is very difficult
to work structured with IT. It is not just the framework in itself, but what it influences if it is not
present: a framework influences all other EA aspects, including the EA process, EA measurement, EA
tools, EA documentation etc. (Bernard, 2004). These exact aspects also show up as immature with the
municipalities. The number lacking a description of the process of using EA is extremely high (90%) as
5
See appendix 9
Page 22 of 112
is the number lacking prescribed guidance for measurement (77%). Few municipalities have its own EA
unit (13%).
The documentation part is suffering as well. More than half (54%) of the municipalities have below
20% of its business architecture documented and almost half (47%) have below 20% of its information
architecture kept up-to-date. There is a serious lack of documentation part in the municipalities again
indicating that EA or EA principles are not used. You cannot do EA without documentation.
Interestingly, the situation is almost reverse, when it comes to documenting the application and
technical architectures. More than a third of all the municipalities have above 60% of its application
architecture kept up-to-date, while the same figure for the technical architecture reaches 74%.
EA tools cross-cutting different lines of businesses, such as an Identity and Access Management tool
(IAM) is a rare tool to find with the Danish municipalities, as 78% do not have one.
3.3 Cross-tabulations
Using cross-tabulations is about selecting one or more responses as constants and then compare them to
other responses which are considered variables. I have chosen my four open-ended questions as
constants and will compare them to other EA aspects to identify any correlation. These questions reflect
the attitude of the CIO’s. And attitude often determines the understanding and use of EA. Therefore I
believe that determining a possible correlation between open-ended attitude-related EA questions with
close-ended hard-fact questions on EA aspects will most likely reveal the level of EA maturity for the
municipalities.
3.4 Determining Correlation
It is outside the scope of this thesis to introduce complex mathematical methods for calculating statistical significance, such as the chi-square analysis, which tests nominal data where observed and
expected frequencies of events are compared. Instead I have used the filter and pivot table function in
MS-Excel as a tool in order to identify the following cross-tabulations.
3.4.1 Correlation on first open-ended question
The question held constant: “One of the purposes of the structure- and task reform is for the municipality in the future should be the primary entrance of the citizens’ contact with the public. Yet KL is doing
a joint public citizen portal at www.borger.dk. What do you think about that?”
159H
There are 72% who believe the portal to be indispensable, 22% have no opinion and only 6% look upon
it as superfluous. The only correlation between respondents thinking www.borger.dk is indispensable
and the rest of the questions is that 26% also have ‘Economies of scale’ as primary motivational factor
for entering into a joint municipal IT co-operation. Looking at the 6% who thinks the portal is
superfluous however shows some interesting facts:
• All have an IT/EA department maintaining a complete overview of services, user interfaces,
technical processes and data sources as part of its portfolio
• None of the municipalities receive support from external IT/EA architects
• All work structured with business oriented IT
• All want either ‘Economies of scale’ or ‘Greater independence of KL/KMD’ as their primary
motivational factor for a joint municipal IT co-operation
160H
Page 23 of 112
•
•
•
•
•
•
•
•
•
All have an IT strategy
All see ‘Lack of resources’ as the greatest obstacle in obtaining a joint municipal IT cooperation
All co-operate already with other municipalities in providing common solutions to common
tasks
All use ITIL as a tool in the organization
All belong to a municipality which demands the use of certain IT tools
All belong to a municipality which primary interfaces between core systems are developed by
bilateral suppliers
All see a potential joint EA program governed by practice
None of them have IAM (Identity and Access Management System)
None of them has a framework
3.4.2 Correlation on second open-ended question
The question held constant: “What could be your municipality’s primary motivation for participating in
a joint municipal IT co-operation concerning solution of common tasks after January 1, 2007?” Since
there are 13 choices I will only focus on the top 3 mode responses: ‘Economies of Scale’, ‘Synergy’
and ‘Improved citizen service’.
3.4.2.1 Economies of Scale
The most apparent attributes describing these municipalities follows:
• None, except one, have an IAM implemented
• The documentation of the business and information architecture is very poor
• 75% find www.borger.dk indispensable
16H
3.4.2.2 Synergy
• All have an IT strategy
• All have reached concrete results through the use of IT as a part of the municipal business
strategy
• All are satisfied with the market supply of courses within IT and its use at a strategic plan
• All document well the EA assets: the business- (40%-60%), information- (40%-60%),
application- (60%-80%) and technical-architecture (80%-100%)
3.4.2.3 Improved citizen service
• 67% find www.borger.dk indispensable, 33% have no opinion
• Not surprisingly, 67% find that their IT strategy in the future can lead to greater usable citizen
service
• 83% have their IT staff trained through external courses
• 67% see ‘Lack of resources’ as the greatest obstacle in obtaining a joint municipal IT cooperation
• 83% do not currently co-operate with other municipalities providing common solutions for
common tasks
• 83% have not published guidelines describing the process of using IT in the business
162H
Page 24 of 112
•
None have an IAM implemented
3.4.3 Correlation on third open-ended question
The question held constant: “What do you see as the greatest obstacle in obtaining this joint IT cooperation?” Since there are seven choices I will only focus on the top two mode responses: ‘Lack of
resources’ and ‘cultural barriers’.
3.4.3.1 Lack of resources
• 87% have an IT strategy
• 87% do not measure its maturity in relation to the use of IT in the business
• 93% have not published guidelines describing the process of using IT in the business
• 80% use ITIL in the organization
• 93% belong to a municipality which primary interfaces between core systems are developed by
bilateral suppliers
• 87% have not implemented an IAM
• All document well the EA assets: the business- (40%-60%), information- (40%-60%),
application- (60%-80%) and technical-architecture (60%-80%)
3.4.3.2 Cultural barriers
• 83% belong to a municipality on Zealand
• 67% find that their IT strategy in the future can lead to greater usable citizen service
• 83% are satisfied with the public supply of IT courses and its use at a strategic level
• 83% have IT procurements approved by the EA function
3.4.4 Correlation on fourth open-ended question
The question held constant:”How do you assess the optimal organisation of common solution of common tasks in a joint municipal IT co-operation?” Since there are two interesting responses to this
question, I will describe both: ‘KL regi’ and ‘between the municipalities’.
3.4.4.1 KL regi
• 71% do not measure the completion of the IT projects
• 94% do not have en EA framework
bilateral suppliers
Page 25 of 112
3.4.4.2 Between the municipalities
• 89% have an IT strategy
bilateral suppliers
• 55% have an EA function/IT at strategic level function
• 55% do not measure its maturity in relation to its use of IT in the business
3.4.5 Other findings
These are other interesting and relevant findings from the survey in relation to the overall problem
question of the thesis.
• 6% have an IT strategy but have not yet achieved any results through this. When asked: “How
much do you believe your IT strategy in the future will contribute with greater usable citizen
service” the response: To a very small degree.
• Only 22% measure the maturity of its organization in relation to its use of IT in the business
o Of these are 86% municipalities on Zealand
o 86% have an IT strategy
o 86% have an EA function/IT strategist
• 71% that do measure the completion of their IT projects, do not measure their maturity in
relation to using IT in the business.
• 83% of the municipalities in Jutland find www.borger.dk indispensable, the rest have no
opinion.
• 58% of the municipalities are inspired by other municipalities when documenting their EA
activities.
• 67% of the municipalities in Jutland find that KL should be the center in providing common
solutions for common tasks.
• All municipalities on Funen find www.borger.dk superfluous.
163H
164H
3.5 Drawing Conclusions
I will draw conclusions in the true spirit of Likert’s ordinal scale: Very mature, mature, neutral, immature, very immature. In ranking the municipalities’ maturity, I look for the use and implementation of
several EA aspects as identified above.
The municipalities which think www.borger.dk is superfluous all seem very mature.
The municipalities whose primary motivational factor is 'economies of scale' in entering a joint
municipal IT co-operation seem immature.
The municipalities whose primary motivational factor is 'synergy' in entering a joint municipal IT cooperation seem mature.
The municipalities whose primary motivational factor is 'improved citizen service' in entering a joint
municipal IT co-operation seem neutral.
The municipalities which have 'lack of resources' as the greatest obstacle in obtaining joint municipal
IT co-operation seem neutral.
Page 26 of 112
The municipalities which have 'cultural barriers' as the greatest obstacle in obtaining joint municipal IT
co-operation seem mature.
The municipalities which see KL as an important player in the optimal organization of this joint IT cooperation seem immature.
The municipalities which see the organization is to take place directly between the municipalities, in the
optimal organization of this joint IT co-operation seem neutral.
In relation to maturity, it is worth concluding that 86% of the municipalities that do measure their
maturity in relation to its use of IT in the business also have an IT-strategy and an EA function
Likewise is it worth noting that Zealand and Funen seem to be the most mature geographical areas in
relation to the need for a common public citizen portal. Municipalities in Jutland seem to be very
dependent on the portal (83%).
3.6 Interpreting Results
Interpreting the results is not an easy task. It involves asking ‘why’ this result is as it is. EA in the
Danish municipalities is overall at a beginner’s stage, or immature. They do have IT strategies all right
but do not document these very well. They do work much in projects, but do not work systematically
with IT within a framework. This can be seen in that only 13% have its EA function. The municipalities
work mostly low-level documenting mainly the application and technical architectures, leaving
strategic IT undocumented. The reason for this absence could be what one of the CIO’s told me in an
interview, when he said that “one of the great obstacles of EA in Denmark, is to bring strategic EA into
the board meetings.” 6 Or it could simply be lack of knowledge of the benefits that EA can give to the
municipalities.
5F5F
The most mature municipalities in Denmark think the public joint citizen portal is superfluous. This is
probably so because they do have their own locale citizen portal. Others think KL is undermining the
vision of having the municipality as the primary entry for the citizens by making a public portal. Those
municipalities having synergy as primary motivation for joint IT co-operation and those having cultural
barriers as the main obstacle in reaching this seem the most EA mature. This is probably so because
since these are deep-rooted EA attitudes and signifies a high level of insight in a potential cross
IT/business municipal co-operation. According to many (Bernard, 2004; Carbone, 2005) culture is an
important element to take into consideration when doing EA. And obtaining synergy is not just a
‘money-centric’ aspect but also incorporates other important aspects such as citizen satisfaction. To
illustrate the importance of culture, I believe, that the reason the municipalities on Funen and Jutland
seem more mature in relation to their fellow municipalities on Jutland, is probably because of
difference in culture. This is not documented, but there is no other correlation that point in any other
direction. The municipalities from Jutland just respond differently (read: at a lower level of maturity) to
most of the questions.
6
Preben Rasmussen Høj, CIO of Sollerod municipality
Page 27 of 112
3.7 Summarizing Conclusions
The study survey reveals the Danish municipalities for the whole part not are at a mature level in
relation to the awareness, propagation and use of enterprise architecture. Even though 65% answered
they have an EA function, they do not use it fully. The following witness to this fact: For the whole part
there is no EA framework, no EA measurement, no EA process, and no EA documentation.
3.8 Making Recommendations
I would recommend more EA pioneer municipalities which would take the first step in order to step up
the EA maturity ladder. But they should not do so alone. KL should back them up. Once a few
municipalities have success, then it can and most likely will spread around to adjacent municipalities as
well, since the culture in knowledge sharing between municipalities in Denmark seems to be very
apparent, especially when it comes to the documentation activities. I would recommend a joint
municipal strategy in this pioneer effort. But before all this can happen, the organization at the national
level has to be in place. I do not yet know if it is in place. Therefore, I will describe and analyze these
for the remainder of my thesis in order to verify if the structure at a national level is set up to support
these joint municipal IT co-operative initiatives recommended in this chapter. And if they are not set up
for it, I will make recommendations for this as well at a later stage.
4. Literature review
4.1 Working towards a common terminology
4.1.1 Introduction
Throughout the past 20 years, many have argued and brought about their viewpoint of how Enterprise
Architecture (EA) is to be defined. As of today there is no common agreement on the matter of defining
what an EA is. I will in this paragraph discuss some of the most common definitions. Before moving on
to this discussion, one can perhaps best catch the vision of the need for enterprise architecture by
comparing it to what will happen if there is no architecture in the enterprise. A classical example to
illustrate the need for architecture is looking at the Winchester “Mystery” House (see figure 5). Here
are the facts of this “un-architectured” house:
•
•
•
•
it took 38 years of construction
– 147 builders and 0 architects
there are 160 rooms – 40
bedrooms, 6 kitchens, 2
basements, 950 doors
there are 65 doors to blank
walls, 13 staircases abandoned,
24 skylights in floors
and no architectural blueprint
exists
Figure 5. The Winchester "Mystery" House. Source: John Gotze’s
slide
Page 28 of 112
It does not take an expert to see something is wrong with this picture. The rationale for having
architecture in building houses is obvious. It is often less obvious why this is necessary in building
companies. So why do we need an architecture in order to build a company or a municipality? Some of
the most obvious reasons 7 for having architecture are given here:
6F6F
•
•
•
•
•
•
•
•
IT costs too much
Costs of managing complexity
Eliminate redundancy
Growing IT ecosystem
Demanding rate of change
Need for info sharing
Outsourcing (BPO)
Future-proofing
These reasons have over time been “transformed” into being the benefits of having enterprise architecture. “If you don’t have strong architecture strategy, everyone does their own thing and you end up with
six kinds of servers and (software) platforms … you get silos of everything and that explodes your
costs” 8
7F7F
4.1.2 What is enterprise architecture?
EA has its roots in the business world. Zachman, the so-called father of EA, was an employee with the
college of Business Administration at the University of North Texas 9, EA is the business view of IT
and should manage IT as a business 10 and EA is a non-technical discipline that should address the
strategic and architectural aspects of IT in the business (Herzum, 2003).
8F8F
9F9F
Most people agree that EA originates from Zachman (1987 and 1992) and his originally designed “The
Zachman Framework for Enterprise Architectures” (also known just as the Zachman framework). His
framework documents how information systems fit into the company by asking very simple, intuitively
questions such as WHAT, HOW, WHERE, WHO, WHEN, and WHY. He explained his newly formed
“framework” by using an analogy to the process of planning, drafting, and building a new home. 11 In
practice it is a schema to help IS architects to systematize the elements of an entire organization and the
relationships between the different aspects of the enterprise, including how a change in one element can
affect another (Zachman, 2005). The framework is two-dimensional; even though he has designed a
three-dimensional EA framework today (we cannot have the founding father of EA not keeping up with
the trends of the time).
10F10F
Spewak 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” (Spewak, 1992). He focuses on the top two layers of Zachman’s framework, the planner
view and the owners view.
Bernard’s approach comprises a more detailed definition: “Enterprise Architecture is both a management program and a documentation method that together provides an actionable, coordinated view of an
enterprise’s strategic direction, business processes, information flows, and resource utilization...it is the
7
Gurpreet S. Pall, Microsoft Architectural Frameworks, 2005, Microsoft Corporation
http://www.flashline.com/content/ambler/agile_ent_arch.jsp?sid=1116166268313-1123631162-101#why
8
Andy Miller, VP of Technical Architecture, Corporate Express
Carol O’Rourke et al, Enterprise Architecture Using the Zachman framework, Thomsen, 2003
10
Peter Herzum, Applying Enterprise Architecture, 2003
11
See appendix 2 or http://www.zifa.com/
9
Page 29 of 112
analysis and documentation of an enterprise in its current and future state from an integrated strategy,
business and technology perspective” (Bernard, 2004).
Schekkerman’s view is holistic as well. He sees EA as “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,
organization 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” (Schekkerman, 2004).
Weill & Ross recognizes that IT is tightly embedded in organizational processes and that the critical
role of architecture is to ensure the desired level of business process integration (sharing of data across
business units) and business process standardization (implementation of the same business processes
across business units). From this they proposed their EA definition: The enterprise architecture is the
organizing logic for a firm’s core business processes and IT processes reflecting the integration and
standardization requirements of a firm’s operating model (Weill & Ross, 2004).
John Gotze, one of the pioneers of eGovernance in Denmark and former counselor in the Ministry of
Science, Technology and Innovation, defines EA as “Integration of the business strategy planning and
the IT strategy” (Gotze, 2004).
The US defines EA as a strategic information base, which can be used as a roadmap to achieve certain
goals (USA Federal CIO council, 2001).
The Open Group, emphasizing open standards and global interoperability, states: “Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those
elements interrelate” (Open Group, 2000).
Lillehagen & Karlsen is more leaning in the direction of Spewaks’ point of view in that they define EA
as “a plan which shows the main features and characteristics of the enterprise and its assets that are to
be analyzed, justified and agreed before the detailed technical design” (Lillehagen & Karlsen, 2005).
Gartner Vice Presidents Chuck Tucker and Dave Aron see EA as “a management process that translates
business strategy into business value. CIO’s with an EA program can use it as a management tool to
further their value proposition to the business” (Tucker & Aron, 2005).
Wegmann & Preiss’ holistic view defines EA as “an integration between the business and the
information technology” (Wegmann & Preiss, 2003).
Lankhorst sees EA as a linkage between many aspects. He defines EA as “a coherent set of principles,
methods, and models used in design and in the realization of the enterprise’s organizational structure,
processes, systems, and infrastructure” (Lankhorst, 2005).
A large number of professionals see EA as “an identification of the main components of an
organization and interactions” (Armour, Kaisler and Pippin, 2002; Chung & McLeod, 2002; Kaisler,
Senate, Armour, Valivullah, 2005).
The list of definitions seems endless. So who is right? Perhaps they are all wrong? Or perhaps they are
all right depending on the circumstances? One thing is for sure and that is with all these different EA
Page 30 of 112
views, evidence of a generally agreed terminology by the enterprise engineering community is lacking.
By comparison the architectures are overlapping in their approaches and the underlying concepts are
not explicitly defined. So the problem of identifying a common EA definition remains unsolved. This
has led many advocating EA to the following “profound”, yet obvious statement: “EA has not been
defined and agreed upon” (Lillehagen & Karlsen, 2005; Schekkerman, 2004; Ross, 2003; Rodd, 1994).
One wonders why such a widespread emerging discipline has not reached consensus on the matter. The
more EA is used, the greater the need for a clear definition. But the current similarities and differences
between architectures can not be perceived by users; and this creates obstacles for its correct
understanding in industry and finally its acceptance and use. The lack of a generally agreed terminology
and semantically enriched knowledge corpus in this domain is also a bottleneck for its efficient
application (Lillehagen & Karlsen, 2005).
Due to this great confusion James Martin (2004) has done more than just observe the absence of a
common EA definition. Confronting customer demands, he lists seven requirements to define EA: 1)
must be in one sentence; 2) may elaborate from that single sentence to make certain clarifications; 3)
must be understandable by executives; 4) must be useful to those who will develop the EA; 5) must be
applicable to a government organization; 6) must be put into context of baseline and target EA; and 7)
must provide the executives with the proper expectations of what can be delivered to them and what
they can use it for. I agree with James Martin’s list of requirements. Therefore with his list in mind, I
choose the best fitted EA definition from the above listed definitions. It is difficult to find a definition
describing all of his requirements all put together in only one sentence. Scott Bernard’s EA definition
seems to be the one closest in fulfilling Martin’s list of requirements with his definition:
“Enterprise Architecture is both a management program and a documentation method that
together provides an actionable, coordinated view of an enterprise’s strategic direction,
business processes, information flows, and resource utilization...it is the analysis and
documentation of an enterprise in its current and future state from an integrated strategy,
business and technology perspective” (Bernard, 2004).
Even though this is a long, on-going
sentence, this fits very well Martin’s
list and I have therefore chosen this
as my working EA definition for the
remainder of this thesis. I believe
however that EA only adds real value
to any enterprise if it provides a
roadmap for gradually enabling a
company to change from its current
operations to the way it wants to do
business going forward.
Figure 6 illustrates the broad perspective and the many facets one has
to consider in order to gain an Figure 6. Enterprise Architecture Program View. Source:
overview of Enterprise Architecture 269Hhttp://www.enterprisearchitecture.info/Images/Extended%20Enterprise/Extended%20Enterprise%20Architecture.htm
in any domain. As noted earlier the
domain of this thesis concerns the public domain of the municipalities and The State.
Page 31 of 112
I presented the design of my study survey in the research design chapter, but did not include which
areas the survey should encompass! I will use figure 6 to extract the questionnaire content. General
research design cannot help me here but figure 6 gives me an overview of which aspects my
questionnaire should deal with: General aspects, motivation, goals & barriers, EA measurement, EA
process, EA tools and methods, EA frameworks, EA governance and EA assets. I believe this figure
very well represents the overall EA aspects to be covered in my questionnaire to the municipal CIO’s.
4.2 Defining the Enterprise
I will now move on to describe what an enterprise is in this context of study. A good definition of
"enterprise" in the context of my study is any collection of organizations that has a common set of
goals/principles and/or a single bottom line. In that sense, an enterprise can be a whole corporation, a
division of a corporation, a government organization, a single department, or a network of
geographically distant organizations linked together by common objectives (Bernard, 2005). There are
a variety of enterprise components to take into consideration (see figure 7). This is another way of
describing Zachman’s six questions: WHAT, HOW, WHERE, WHO, WHEN, and WHY. Codd’s
figure indicates that the external environment provides input to the enterprise AND to the strategy. The
strategy influences the “six questions” or EA aspects, just as it guides the use of information and
technology. These provide input to the output results. These results could be EA artefacts
(documentation of EA), as well as “doing business the EA way” behavior. Note that there is only
arrows going to ‘technology’, not from it. This indicates business driven use of IT, where the
technology is aligned with the business, not reverse. Finally, Codd sees EA as a process, which he
indicates by drawing the ‘Transformations through organizational processes’ arrow going from input to
the enterprise to output into the environment. Codd focuses much on the act of ‘doing Enterprise
Architecture’. Not just talk about it, plan it or document it, even though these activities of course also
are essential.
Figure 7. Enterprise components. Source: Codd 1994.
In this study the definition of an enterprise depends on the level we look at: the municipal or the state
level. At the municipal level an enterprise is all the municipals together. At the state level an enterprise
comprise all the different public national authorities within the public sector. Since I believe you cannot
Page 32 of 112
separate the municipalities and the state, I will treat them as one entity or as one enterprise and call this
Denmark Ltd. This means that the customer is the citizen and the products are the services offered.
4.3 Defining the Architecture
The architecture of a system is the system’s fundamental organization, embodied in its components,
their relationships to each other and to the environment, and the principles guiding its design and
evolution.
Another view of EA is looking at its contextual usage. Usually, architecture has various meanings
depending on its contextual usage: 1) A formal description of a system at component level to guide its
implementation, 2) the structure of components, their interrelationships, and the principles and
guidelines governing their design and evolution over time and 3) organizational structure of a system or
component. To summarize, an EA should generally be organized in a manner that supports reasoning
about the structural properties of the system. It should define the different components, which
contribute to the overall system, and it should provide a plan from which the system can be developed
(Open Group, 2000).
CTO at Cap Gemini, Steve Jones, says “a decent architecture would take all the "Enterprise" products
and stick them together into something that works.”
4.3.1 Four common viewpoints on architecture
For practical approaches, a limited set of architectural dimensions is widely adopted (NIST 1989,
Armour et al. 1991a, Hasselbring 2000, The Open Group 2002, Buchanan and Soley 2002, Heffner
2002). The set commonly consists of the following concepts although the terms used may vary:
1.
2.
3.
4.
Business/Processes Architecture
Information/Data Architecture
Logical (Systems/Applications) Architecture
Technology Architecture (Application technology and infrastructure)
This set of EA dimensions unfortunately lack academic argumentation and is mostly agreed on as
practical approaches. The more CEO’s see the rational for an EA, the more needful I think will be an
academic approach to this discipline. We have seen this natural evolvement with traditional systems
engineering, in OO systems engineering, in component based development and in recent years with
Service Oriented Architecture. Why not implement an EA engineering academic approach? Both public
and private companies are now adopting EA certification as part of their standard training program,
particular in the US. I will not pursue this observation further at this time. Instead I will in the following
discuss the arguments and rationale for doing Enterprise Architecture.
4.3.2 Why Enterprise Architecture?
Why use enterprise architecture at all? What are the benefits? Most agree that the benefits of EA can be
summed up using three words: better, faster, cheaper (Kaisler, 2005; Ambler et al, 2003). Other sees the
benefits as a support in the planning process and management decisions (Bernard, 2004; Spewak,
1992). But it is important to realize that these benefits come at a price. You have to be willing to invest
in the underlying organizational and cultural structures to support them. You need to recognize the fact
Page 33 of 112
that these costs exist and ensure the better-faster-cheaper benefits outweigh them. Many examples can
be taken to illustrate the justification of using EA. Here is one:
US Agencies with enterprise architecture scores less than 3.0 spent 8.2% of their
discretionary budgets on IT. Agencies with enterprise architecture scores higher than 3.0,
spent 6.6% of their discretionary budgets on IT. Agencies that scored higher than 3.3 on
their enterprise architecture assessments, spent only 3.8% of their discretionary budgets on
IT. 12
1F1F
Some believe return on investment is irrelevant in lieu of net present value, the plethora of payback
algorithms, or concepts in real options. But the bottom line is that return on investment is a strategic
approach to measure the value of any activity, especially enterprise architecture. David F. Rico 13 has
listed his set of principles for successful Return on Investment (ROI) in your enterprise:
12F12F
•
•
•
•
•
•
•
Use ROI as a success factor: Use ROI to drive EA. The goal of EA is to align an organization’s strategy with its information technology (I do not agree with this goal though. I believe
the information technology should be aligned with the business strategy not the other way
around). By implication, a strategy cannot be realized without this alignment.
Etch the desired benefits in stone: Identify a core set of benefits you wish to realize from EA.
Then establish measurable goals for operating efficiency, cost reductions, staff reductions,
customer satisfaction, computing budgets, and economic growth. In other words, convert
improvements into money.
Establish early ROI objectives: Establish ambitious ROI objectives for enterprise architecture
based on tangible measures of costs and benefits.
Operationalize a core set of metrics: Define a set of clear and measurable, and quantitative
economic benefits for enterprise architecture. These could entail people, time, budgets,
customers, throughput, volume, bandwidth, computers, and maintenance. Common mistakes to
avoid are failing to define metrics, defining qualitative ones, or defining far too many metrics.
Continuously measure the payback: Measure the return on investment of enterprise
architecture early and frequently. Measure the payback at regular intervals along with normal
project management activities, such as cost, time and earned value reporting.
Use automated tools to do the work: Use an integrated project management reporting system
with built-in return on investment tracking and reporting function. No point in spending a lot of
time learning all the payback formulas or hiring a return on investment manager.
Standardize ROI reporting: Create a system for measuring and reporting measures for the
return on investment of enterprise architecture.
The need for enterprise architecture can certainly be justified by the many reports documenting the
benefits outweighing the costs. And I strongly agree with David F. Rico’s seven critical set of principles in order to successfully measure the Return on Investment of the enterprise architecture.
To be effective, enterprise architecture must be more than models for business, information, and
organization. Butler Group recommends that the process encompass both services architecture and the
deployment of a services platform. Only by embracing an end-to-end methodology and framework will
organizations avoid analysis paralysis and separate islands of knowledge, maximizing the undeniable
benefits and cost savings available from the use of Enterprise Architecture.
12
13
Burk, Federal Enterprise Architecture Program Management Office, Sept. 2006
David F. Rico, A Framework for Measuring the ROI of Enterprise Architecture, http://davidrico.com/rico05a.pdf
Page 34 of 112
In relation to the study at hand with the municipalities
merging, a good merging of the IT generates less
costs of operation. According to IBM, an IT
optimization analysis can help the Danish
municipalities merge their IT-organizations, bring
down the IT costs, make the operation of IT more
effective and optimize the IT infrastructure. This,
IBM suggests, is possible by analyzing seven
different key areas (see figure 8) 14.
13F13F
It is IBM’s experience from dealing with many
mergers and structural changes in public regi that in
Figure 8. IBM's seven key areas for mergers
order to be able to gain the real potentially savings and
efficiency benefits the prerequisites are:
• The new common IT-organisation is well defined.
• The IT strategy and the e-policy for the new municipality must be defined and known.
• IT Governance and decision making bodies for the new organization must be well defined and
established very early in the process.
• An attempt should be made to use a well tested and experience based structure and method in
connection with the task of optimization, thus securing that the optimazation initiatives support
the IT strategy and that the merging will go through with minimal risk for IT operation.
• Consolidation opportunities within data communication, server- and data storage technology as
well as telephony will be exploited.
I find these prerequisites extremely relevant and important for the merging municipalities.
4.4 Legacy of EA
In order for us to understand EA more fully, we have to go back and look at its origin. Zachman is
credited with creating enterprise architecture even though it has its foundation in systems analysis
principles dating all the way back to the 1960’s. Early systems analysis techniques included
flowcharting, structured design, structured analysis, and information engineering. The Zachman
framework and the U.S. Department of Defense Architecture Framework (DoDAF) are huge in terms of
models. Zachman requires 30 unique models, while DoDAF “only” requires 26. In the US today, over
46 of the more than 100 U.S. federal agencies use enterprise architecture, a wide variety of maturity
models to assess their progress and a plethora of never ending tools.
4.4.1 Relationship to systems analysis and design
Enterprise architecture can put the system development approaches and embedded documentation
techniques in an overarching context and unifying framework. Without this context, systems
development efforts throughout an organization run the risk of being disjointed and duplicative,
something we have witnessed for the past decades.
14
http://www-304.ibm.com/jct03004c/industries/publicsector/dk/da/efficientit
Page 35 of 112
4.4.2 Relationship to strategy and business planning
In most EA literature there is a clear explanation of the relationship between strategic planning,
business planning, and information technology planning. IT resources are increasingly becoming a
commodity, and therefore the need to treat IT as a business enabler continues to grow in many public
organizations. In recognition of this, EA’s identification of integrated IT solutions organization-wide
(crosscutting) and mission-specific (vertical) requirements is one of the most important elements in
planning EA in a complex environments such as the public sector. Strategic goals and business
requirements should drive IT solutions, and EA’s contribution to this alignment is crucial.
4.4.3 Relationship to component-based and service-oriented architectures
The public sector consists of a large and complex structure which operates in horizontal as well as
vertical ways trying to fulfill the needs of a complex and ever
changing environment. Therefore in choosing an EA framework to
support this, it must include loose-coupling and internal standardized
integrated elements which support organization-wide (between
municipalities) and mission-specific (in one sector, e.g. the
environmental sector) requirements. As figure 9 illustrates, Bernard’s
EA3 Cube Framework 15 supports exactly that with its “plug-and-play”
components – or building blocks – which are increasingly interoperable and integrated due to the so-called standards thread that promotes non-proprietary solutions.
14F14F
Figure 9. Bernard's EA3 cube.
Source: Bernard, Scott (2004)
4.4.4 Relation to social aspects
Traditionally speaking, EA is about aligning the IT-architecture in relation to the enterprise’s business
strategy, thus complying with a traditionally top-down view. But sustainable EA must encompass more
than that because it is developed, supported and used by people. It is made by people, for the people
and to the people within the enterprise. Therefore, the social and cultural aspects of the enterprise have
to be a part of the establishment and the sustainability of a successful EA. Hence a bottom-up view.
One could go so far as to speak of a social edition of EA as a discipline or SEA: Social Enterprise
Architecture. This would certainly add a more holistic view of EA as both the technical and the social
aspects are described. One of the systems development approaches which combines the scientific
approach with the systems approach in an integrated approach is called the MULTIVIEW
methodology. 16 I will not go further into this methodology here, but instead in the next focus in on the
prerequisites of starting enterprise architecture.
15F15F
4.4.5 Development of Systems Development
Systems development has undergone tremendous changes in recent years. Going back to the 1970’s and
1980’s we saw how structured procedural development was dominant on the market. Later came objectoriented analysis (OOA) and object-oriented design (OOD), Component based development (CBD),
and in recent years web services have gained much popularity, often used in connection with service
oriented architecture.
15
16
See appendix 3
D.E. Avison and A.T. Wood-Harper, 1990
Page 36 of 112
Since 1995, Gartner has used hype cycles to characterize the over-enthusiasm or “hype” and subsequent
disappointment which typically happen when introducing new technologies. These hype cycles also
show when and how technologies move beyond the hype, offer practical benefits and become widely
accepted. According to Word Spy 17, a hype cycle is:
165H
16F16F
A sequence of events experienced by an overly-hyped product or technology, including a
peak of unrealistic expectations followed by a valley of disappointment when those
expectations aren't met.
There are five phases of a hype cycle: 1) technology trigger, 2) peak of inflated expectations, 3) trough
of disillusionment, 4) slope of enlightenment, and 5) plateau of productivity (see figure 10). The first
phase of a hype cycle is the technology trigger or breakthrough where the product is launched, or an
event that generates significant interest. The next phase typically covers the publicity and overenthusiasm and unrealistic expectations. There are usually more failures than successful applications of
a technology. Technologies enter the next phase, trough of disillusionment, because they fail to meet
the expectations and quickly become unfashionable. The press usually avoids the topic and the
technology. Although the press does not cover the technology, some businesses still go through the
slope of enlightenment and experiment to understand the benefits of the technology. A technology
reaches its plateau of productivity as the benefits of it become widely demonstrated and accepted. The
final height of the plateau varies according to whether the technology is broadly applicable or pertains
only to a niche market.
Figure 10. Gartner's hype cycle. Source: http://www.gartner.com/DisplayDocument?doc_cd=130115
16H
17
http://www.wordspy.com/words/hypecycle.asp
Page 37 of 112
As can be noticed from figure 10, EA is not on the hype cycle at all. If I have to relate it to an adjacent
technology, SOA can be compared to EA which is entering the trough of disillusionment and within
two to five years will reach its plateau.
4.4.6 Development of EA
Enterprise architectures became popular when John Zachman developed his framework for dealing with
large information systems (Zachman, 1987). These frameworks originally focused on data processing
using mainframe computers, so their emphasis was on the data aspects of a business. Later there was an
emphasis on information processing in the business (during the so-called Information Age). During
recent years, there has been an increasing interest in “knowledge management” and services, since it
has been recognized as a key ingredient in the success of businesses today. However, architecture
frameworks still have a focus on the information aspects of the business and little if any treatment of
the knowledge aspects.
4.4.7 What is Service-Oriented Architecture?
Since I will be using Service-Oriented Architecture (SOA) as a concept, I will state my working
definition of it as a part of the ‘Working towards a common terminology’ chapter. Since the primary
focus of this thesis is not SOA, I will make this brief.
The general perception of a service-oriented architecture is that it is a style of application design that
includes a layer of services. A service, from this limited perspective, is just a block of functionality that
can be requested by other parts of the system when it is needed. These services have a published set of
methods, known as an interface. Usually, each interface will be associated with a particular business or
technical domain. So there could be an interface used for authentication and another interface used to
create and modify a sales order etc. 18 CBDI 19 defines SOA as:
17F17F
18F18F
“Service Oriented Architecture (SOA) is the policies, practices and frameworks that enable
application functionality to be provided and requested as sets of services published at a
granularity relevant to the service requestor which are abstracted away from the
implementation using a single, standards based form of interface”.
CBDI’s definition will also be my working definition of SOA throughout this thesis.
4.4.7.1 Benefits of SOA
The main benefits of SOA
• Loosely coupled applications (change in a service does not affect the application as long as the
interface remains intact)
• Location transparency (the service can reside anywhere in the world)
• Code reuse (easy with use of UDDI, WSDL and XML)
• Focused developer roles (assigning specialized developers to specific tasks)
• Greater testability (through published interfaces with NUnit)
• Parallel development (due to the only interaction between services is through interfaces in the
different layers)
167H
18
19
Bruce Johnson, http://objectsharp.com/blogs/bruce/articles/235.aspx
David Sprott and Lawrence Wilkes, Understanding SOA, September 2003, CBDI Journal
Page 38 of 112
•
•
Better scalability (improved response time for a service without effecting the calling application
if placed on web farms)
Platform independent (independent of HW and SW)
4.5 Merging of disciplines
4.5.1 SOA and EA
Rasmus Knippel took on an evolutionary approach in his own research 20 of SOA and EA. One of the
main issues of his research was to describe and analyze the evolution of SOA. A large part of his
research entails a comparison of EA artefacts with SOA artefacts, and here he found many similarities.
19F19F
Some of his key findings:
• The higher level of abstraction of SOA artefacts, the closer the resemblance to EA.
• The real value of the artefacts is to be found in the relationship between them.
• EA at its most mature state, called Nirvana, equals the definition of SOA.
• EA is founded from a business perspective and SOA is founded from a technical perspective.
• EA is often seen as a top-down method where SOA is often seen as a bottom-up method. They
both show strength and weaknesses but the key is to get the best out of both.
• SOA is the nirvana of EA.
• SOA and EA share common goals such as creating interoperability, reusability and eliminate
duplication.
• SOA can make EA operational.
• It is a risky business if EA has to fix some of the problems SOA causes! And this can happen if
the organization is not mature enough for SOA.
4.5.1.1 The chicken or the egg
This is a reference to the causality dilemma which arises from the expression "which came first, the
chicken or the egg?" Since both the chicken and the egg create the other in certain circumstances (a
chicken emerges from an egg; an egg is laid by a chicken) it is ambiguous which originally gave rise to
the other. Compared to EA and SOA, then what comes first: EA or SOA? Or asked more specifically,
what drives what? Gurpreet S. Pall puts it this way: “If you don’t do EA, you can’t do SOA”. I believe
you can do EA without SOA if doing so in a closed domain, but you cannot, like Gurpreet stated, do
SOA without EA.
The municipalities and their future IT solutions are not however based on a closed domain, but in an
ever changing environment reflecting complex, social structures. And if the municipalities are to cooperate they will need a technology which ensures interoperability and agility, and that is exactly what
SOA provides. But still EA has to be the driven factor of the two because it originates from the business
view and as stated earlier it has to be the business that drives everything else. This does not mean
however that new technology cannot affect business vision and goals and even enable new business
opportunities. But IT has been and will always be a tool. IT is only interesting because somewhere in
the world people have a need for information that IT can deliver in a very effectively manner, e.g.
through web services in a SOA.
20
Rasmus Knippel, SOEA, 2005, http://knippel.org/thesis/SOEA_censored.pdf
Page 39 of 112
Figure 11. SOEA. Source: Rasmus Knippel, 2005
According to Rasmus Knippel, EA comes first and SOA can be seen as a plug-in to EA as the driving
force to achieve interoperability. SOA can, but does not have to, result in EA and vice versa. SOA and
EA must be aligned to each other and looked upon as a totally new concept: SOEA (see figure 11
above). This is the next step up the evolutionary ladder according to Knippel, who claims that this
alignment of SOA and EA artefacts into a common frame of reference will ensure the continued
success of both SOA and EA.
4.5.2 To be or not to be…
…that is the question, is probably one of the world’s most used quotes. The German philosopher
Schopenhauer commented on Shakespeare’s Hamlet quote by saying that:
“The essential purport of the world-famous monologue in Hamlet is, in condensed form,
that our state is so wretched that complete non-existence would be decidedly preferable to
it. Now if suicide actually offered us this, so that the alternative "to be or not to be" lay
before us in the full sense of the words, it could be chosen unconditionally as a highly
desirable termination ("a consummation devoutly to be wish'd" [Act III, Sc. I.]). There is
something in us, however, which tells us that this is not so, that this is not the end of things,
that death is not an absolute annihilation”
– Schopenhauer
Now what does this have to do with EA? Most municipalities in Denmark do not use EA today as a
program. Who said “silver bullet?” I believe if rightly planned and applied it is one silver bullet. Just
like SOA is one silver bullet. There is no single silver bullet which takes care of all your problems. In
my experience no product will ever solve all your problems. However it might help solve your
problems – if used right. Or as Kristian Hjort-Madsen puts it: “The only thing that can make enterprise
solutions work is YOU. And what you will probably find is that it is not the product that will be your
biggest challenge – your biggest challenge is the organization. Having a tool working across an entire
enterprise requires more than the tool, it also requires that it is used in a controlled fashion. An
endeavor that requires full organizational support” (Madsen, 2006). The reference to Hamlet is that
either we do EA all the way – one step at a time – or we don’t do it at all. But unfortunately it is not all
organizations/enterprises that are fit for doing enterprise architecture. The following will discuss these
issues.
4.6 Prerequisites to enterprise architecture
Some organizational cultures are better suited for EA planning than others. EA planning is well suited
to organizations that have long-range goals and plans, a cooperative team approach to management
decisions, total quality management programs, and a desire to invest in new products and procedures
leading to significant revenue or savings in the future (Spewak, 1992). Conversely, EA planning is not
appropriate for an organization that places greatest value on quarter-to-quarter profits, quotas, budget
slashing, and short-term projects. EA planning should not be attempted in an unfavorable climate
Page 40 of 112
(Spewak, 1992). The organizational culture in the merging municipalities seem to support the use of EA
planning due to their long-range goals and plans that need to be carried out as part of the merging
process. The team approach to management decisions will be one of the most prevalent characteristic
features between the new merging municipalities and they will have to invest in new IT products and
procedures in order to live up to the government’s vision of providing better service towards the
citizens, especially seen in the light that they have to do this at lower costs. On the other hand, one of
the benefits of EA is overall cost reduction.
In the Danish municipalities there is no demand that they have or will implement EA, but it cannot be
excluded that this will come at a later stage, even though the study survey report reveals that more than
90% of the municipal CIO’s would rather have current practices govern IT instead of by legislation. But
the Danish municipalities do have to live up to a number of demands regarding eGovernance including
eDay1, eDay2, eInvoice etc. It is therefore likely that facets of EA demands will meet the new merging
municipalities in the future.
4.6.1 Enterprise Architecture practices
4.6.1.1 Enterprise architecture and business objectives
Enterprise architecture does not start with technology. It must begin with a strategic framework, the
vision, goals, and the main business activities (Lillehagen et al, 2005). As mentioned earlier, according
to Bernard, EA is both a management program and a documentation method. When using EA as a
documentation method, it provides four elements: 1) an EA approach modeling the framework and
implementation methodology, 2) a current architecture, which gives a view of as-is strategies, processes
and resources, 3) a future architecture, which gives a view of to-be strategies, processes and resources
and 4) an EA management plan, describing how to move from the current to the future EA. This timebased view of EA in a current and future state has been further elaborated by James Martin (2004): An
EA is a specific arrangement of business objectives, features and functions. The purpose of a “shouldbe” (target) EA is to maximize a set of business goals and objectives given a set of constraints,
conditions, and challenges. The purpose of “as-is” architecture (baseline) is to document the current
arrangement such that a transition to the desired target state (target line) can be determined. Several
recent EA scribes advocates for this current-target view (Carbone, 2004; Bernard, 2005). The transition
from a current to a future state calls for the need to identify enablers of transformation.
4.6.1.2 Enterprise architecture as a ‘skeleton’
Independently of business goals or strategies, EA is, first of all, the foundation of enterprise systems
(Lillehagen et al, 2005). According to ISO 15704 (2000), an architecture is a description of the basic
arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity).
The software community shares a similar view: EA is the fundamental organization of a system
embodied in its components, their relationships to each other and to the environment and the principles
guiding its design and evolution (IEEE 1471, 2000). According to Lillehagen et al (2000), an
architecture seen from a general perspective must:
•
•
Have properties that can be verified with respect to user needs (ex. open or closed architecture,
interoperable or not, centralized or decentralized...).
Be simple so that business people can easily understand, check, analyze, discuss as a
‘language’ shared at corporate level.
Page 41 of 112
•
Have a style (by comparison with construction where architecture can represent some particular
characteristics of a building such as ‘gothic’, ‘romaine’…). EA should be able to characterize
enterprise systems (ex. ‘fractal’, ‘holonic’, or ‘agile’…).
4.6.2 Enterprise architecture methodologies
ISO 15704 (2000) suggest that there are only two architectures that deal with enterprise integration: 1)
System architectures and 2) Enterprise-reference projects.
Enterprise integration deals with the design of the system, e.g. representing the system or subsystems in
terms of its structure and behavior of the overall enterprise (this is also sometimes known as “type 1”
architectures).
Enterprise-reference projects deals with the organization of the development and implementation of a
project such as an enterprise integration or other enterprise development program (this is sometimes
referred to as “type 2” architectures). Specifically, this deals with framework aiming at structuring
activities/tasks necessary to design and build a system. For instance, Zachman’s architecture is type 2
architecture.
4.6.3 The challenges of enterprise architecture
Fundamentally, the problem with enterprise architecture is communication (Schekkerman, 2004).
Another problem, which could be a part of Schekkerman’s statement, is reaching some level of
common understanding of the EA definition. Even experienced EA professionals do not agree on this
definition. And maybe never will, until a neutral forum presents a commonly agreed and well tested EA
definition, like W3C is for the Internet, it would be nice to have an EAC (Enterprise Architecture
Consortium) present. The Open Group is probably the closest consortium in fulfilling this need.
Perhaps it is not necessary to have such a consortium? Perhaps every enterprise is responsible for
outlining its own EA definition. This may be the case, as we have seen it for a number of years now but
it makes it extremely difficult to have common ground in referencing standards and interoperability in
the midst of a jungle of definitions and enterprise architecture frameworks. Therefore I will later
analyze relevant frameworks and identify which will best fit to the municipalities EA activities and
which will best fit to the State EA activities. But before I undertake this analysis, I will address two
important factors: EA planning and EA maturity and measurement.
4.7 The EA planning process
4.7.1 Introduction
One of the worlds leading experts on personal time management, Alan Lakein once said: “Planning is
bringing the future into the present so that you can do something about it now.” 21 Paraphrased a bit this
could be relevant on the subject of Enterprise Architecture (EA) as well: Planning an EA is bringing the
future state of your enterprise into the present, so that you can do something about it now.
20F20F
21
http://www.brainyquote.com/quotes/authors/a/alan_lakein.html
Page 42 of 112
4.7.2 Planning an enterprise architecture
I believe one of the very first steps is the planning phase. According to Spewak, Enterprise Architecture
Planning (EAP) is the process of defining architectures for the use of information in support of the
business and the plan for implementing those architectures. There are three keywords in Spewak’s
statement: architectures, defining and a plan. Usually EA operates with three architectures: data
architecture, applications architecture and technology architecture. The word defining implies a
definition of the architecture, not the design of it. EA planning does not design systems, databases, or
networks. The design and implementation work is initiated after the EA planning definition process has
been completed. The third important word is plan. Generally speaking, the architectures define what is
needed, and the supporting plan defines when the architectures will be implemented. Architectures by
themselves can provide useful definitions, standards, and ideas. But architectures without plans, no
matter how thorough or good technically, usually end up sitting on a shelf gathering dust, never
reaching implementation. In other words, in the absence of a thorough plan, “enterprise architecture
frequently does not get beyond the end of the runway in many businesses, as it needs more than the odd
evangelist within the organization to ensure adoption throughout the whole enterprise” (Butler Group,
2005).
People at all organizational levels need information in order to do their job well. When asked the
question: “With respect to information, what is needed to fulfill your objectives or do your job?” all
responds from the president, vice-president and on down with the same five answers (Spewak, 1992):
1.
2.
3.
4.
5.
Access to data in a useful format when and where needed
Ability to adapt to changing business needs
Accurate and consistent data
Share data across the organization
Contain costs
5 Success Factors Listed by Executives
Access to data when and where needed
Ability to adapt to changing business needs
Accurate and consistent data
Share data across the organization
Contain costs
I.S. Mission
Timely access to needed data
Flexible, maintainable systems
Data integrity and standards
Data/systems integration
Cost effectiveness
Table 2. Success factors yield I.S. mission. Source: Source: Spewak (1992)
4.7.3 Obstacles for successful Enterprise Architecture Planning
The large majority of EAP projects are never completed. 22 In general, there may be three reasons for
this: 1) EAP projects may begin on the wrong track by having unreasonable objectives or unrealistic
expectations, 2) selecting an approach that will not achieve the desired result in the time allotted and 3)
the participants are unfamiliar and inexperienced with EAP. More specifically, I find it especially
relevant to find out why this is so.
21F21F
According to Spewak, the most apparent obstacles to successful EA planning are the ones seen in table
3. In order to identify these obstacles there are certain symptoms, or statements, which typically
22
Spewak (1992), Enterprise Architecture Planning
Page 43 of 112
originates from the management – the single most important core supporting EA. A relevant solution is
suggested as to what to do in order to overcome the obstacle.
An example could be the identification of the second obstacle: “Commitment of resources to enterprise
architecture planning.” If management would respond to your EA initiatives with “go ahead with your
EAP, but you can only use three people for two months” you know that there is a lack of commitment
of resources to enterprise architecture planning. Management’s use of words like “you” and “your”
indicate that they do not accept EAP, will distance themselves politically, and by limiting resources,
may make it impossible to complete EAP or do it well. The end result then appears to be your fault, not
theirs. The solution to overcome this obstacle could be to prepare a sales speech to the top management.
Obstacle to overcome
Symptoms
Solutions
1. Awareness, recognition and
acceptance by top management
“Why should we do EAP?” or “Are
other companies using EAP and what
have been their results?”
2. Commitment of resources to
enterprise architecture planning
“We need to do EAP, but we cannot
afford to do it now because...” or “Go
ahead with your EAP, but you can only
use three people for two months.”
“Our company doesn’t believe in
strategic planning” or “We only have
time to shoot the alligators, not to drain
the swamps.”
Educational process: Make presentations on EAP
concepts to management. External consultants
present architecture benefits and opportunities.
Provide management with books/published
articles on EAP methods and results of planning
in other companies – especially competitors.
Make a sales pitch to the management.
3. Unfavourable corporate culture
4. Political differences regarding
responsibilities for enterprise
architecture planning
5. Lack of credibility of planning
leaders
Multiple departments vying for EAP
responsibility.
6. Inexperience with EAP and lack of
training
“What will be the next step?” or “What
is the purpose of this step?”
7. Finding the “best” methodology
Lengthy debates over methodologies,
tools, consultants, seminars, vendors
and products.
8. Educating IS personnel in new
technologies
Low attendance at internal courses and
presentations. Resistance to new
products or techniques.
“Why do we need EAP when our
current applications are operating just
fine?” or “There is nothing wrong with
the way we’ve been developing systems
for the past 20 years.” or “If EA is so
beneficial, why did we not do EAP
several years ago?”
“We should wait until this new suchand-such product is released” or
9. Satisfaction with current application
methods
10. Few or inadequate tools
“They really don’t understand the way
we operate” or “Here come the EA
planners again”
EAP should not be attempted in an unfavourable
climate. If there is only minor amount of adverse
culture, try one of two strategies:
1.
Avoid selecting team member and leaders
who display this arrogance.
2.
2. If no. 1 is not possible, maybe some
component of EAP could be useful until a
more favourable climate appears.
The most effective is to have the ultimate
responsibility rest with one single person or
department. It could be a temporary department
or an existing one.
1.
Select respected team members from across
the enterprise
2.
Use modern EAP methods and tools
3.
Place articles about the EAP in an internal
newsletter
Make an educational program for EAP.
1.
Educational seminars taught by experienced
practitioners
2.
Public seminars and conferences
3.
Consultants with EAP experience to make
executive overview presentations
There is no “best” methodology. Any
methodology is better than none. By consensus,
select a methodology that is understandable can
be accomplished in a reasonable amount of time
and can be completed within the budget and then
stick with it.
Plan an educational awareness program, that will
convince IS personnel of the advantages of EAP
Focus on the positive impact EAP will have on
future systems and not the causes of current ills.
Explain EAP is a relatively new process, requires
skills heretofore unavailable and that tools and
technology now have advanced to the point of
supporting EAP.
Avoid planning products that claim to “do it for
you”
Page 44 of 112
11. Uncertain payback and rate of
return; Expecting immediate results
“Postpone EAP until the decision as to
Business Intelligence products has been
made.”
“What will EAP do for me this year?”
12. Fear of loss of data control /
ownership
“...my data...” or “...my files...”
13. Substantial up-front costs; benefits
difficult to measure
“Why is EAP expensive?” or “What is
the payback for EAP?”
14. Inaccessible or uncooperative users
Point out the following: The architectures
produced by EAP are immediately useful. With
sufficient resources, an integrated architecture
and plans can be developed in four to eight
months. New systems developed from the plans
can be implemented faster than those without
architectures.
Explain that data is a shared business resource
like the buildings, equipment, furniture and
materials.
Most people who claim that the benefits of EAP
are hard to measure use this as an excuse for
deeper-rooted reasons. Find out what these
reasons are and deal with these first and this
obstacle should disappear.
EAP should not be attempted without the full
cooperation, support, and involvement of the
enterprise areas. Management MUST view EAP
as their people producing their plans if it is to be
credible.
“Do your planning, but don’t involve
any of my people” or “submit your plan
when it is finished, and we will
evaluate it” or “All of our best people
are fully committed to other activities,
but we recently hired two graduates
from the university who are not
particularly busy, so use them for
EAP.”
15. Delusions
“I can do EAP myself” or “I don’t need One should be aware of such impressions and
assess them honestly.
consultants” or “Though there is little
support for EAP, when the architectures
are presented, management will see and
understand the benefits, accept the
architectures and approve the remainder
of EAP.”
Table 3. Obstacles for Enterprise Architecture Planning. Source: Spewak (1992)
With all these obstacles apparent already in the planning phase of enterprise architecture it is no wonder
that most EAP efforts, do not succeed. Any management within the municipalities or the State, who
seriously want to create plans for enterprise architectures, should examine table 2 and identify which
obstacles poses the greatest threat to their domain.
4.7.4 Key Factors to Successful Enterprise Architecture Planning (EAP)
In order to complete, implement and maintain successful enterprise architectures and plans, research
from several enterprises that has a proven record in the area, clearly indicates 10 essential factors for
success. 23
2F2F
First, commitment and support from the management is essential. This involves obtaining adequate
funding and gaining credibility. A common vision should be reached and the presentations of the plans
should include the concepts, vision and mission in a way that virtually assures management
commitment and support. Without management commitment of resources, EAP simply cannot succeed.
Second, there must be end-user and management participation and cooperation. This involves all the
relevant people setting the necessary time aside for interviews, reviews and feedback during the entire
23
Enterprise Architecture Planning, p. 32
Page 45 of 112
enterprise survey. At presentations all attend. Realistic and credible plans are developed for the
business.
Third, there must be an effective project leadership and a work plan. Successful EAP projects have
leaders who adopt a methodology, develop a clear and concise work plan that is easy to follow and
motivate and guide EAP through to conclusion.
Fourth, there is a reasonable balance between the three important factors a) scope and objectives, b) the
level of detail and c) the resources and time allotted. The adequate details of the enterprise are
described within the constraints of available time and resources. The scope of the enterprise is not too
broad to be accomplished or to narrow to exclude the important details of shared data.
Fifth, the EAP is carried out by a qualified team and the use of consultants with practical experience.
The members of the team are well respected and have extensive experience.
Sixth, there must be an effective use and management of tools to support the EAP. These tools assist
the EAP process, enable business information to be analyzed, improve the presentations of the
architectures and plans to the rest of the organization and enable developers to build from the
blueprints.
Seventh, EAP is performed and promoted in a manner consistent with the corporate culture, making it
easier for all in the organization to support EAP and cooperate with the team.
Eight, a high profile of circulating interim documents for review and comments is maintained. This
way, the management could monitor the progress of the EAP, business people could provide feedback
to secure that the architectures and plans would fulfil their long-term requirements.
Ninth, effective presentations are made in order to keep team members fully informed of the progress
and to create a positive image about EAP throughout the entire organization. These keep a business
orientation.
Tenth, the 80/20 rule is followed. This – simply put – state that there is no perfect plan. More
specifically, planners cannot afford to get bogged down by “insignificant details.” Detail and accuracy
may need to be sacrificed somewhat to formulate the architectures and plans within the allotted time.
Eighty percent completeness and accuracy in each phase is considered “good enough” to produce
reasonable, feasible architectures and plans.
These above-mentioned 10 factors irrevocably impose rhetorical questions any management team
should ask themselves in order to succeed with EAP: Can we describe a strategy to put all 10 success
factors in place? Have we had any successful planning projects in our organization, and why were they
successful?
Page 46 of 112
4.8 eGovernment Maturity
4.8.1 Introduction
An eGovernment maturity model provides us with guidance on how to gain control of our processes for
developing and maintaining eGovernment services and how to evolve toward a culture of excellence in
providing and managing eGovernment. A maturity model can also guide us in selecting process
improvement strategies by determining current process maturity and identifying the few issues that are
most critical to eGovernement quality and pocess improvement. eGovernment could be defined as
governments providing information about services, as well as the ability to conduct government
transactions, via the Internet. 24
23F23F
4.8.2 Maturity of the State of Denmark
As concluded in chapter 3.7 the Danish municipalities are not considered to be at a mature level in the
awareness, propagation and use of enterprise architecture. But what about the national level in
Denmark? At what maturity level is that to be found in? According to figure 12, Denmark is among the
top 5 mature e-Governments in the world. This is not bad at all. But what qualifies Denmark for this
position?
Figure 12. Maturity of eGovernment. Source: Slide from John Gøtze
Certainly the way the State has organized itself in a broad manner with participating parties from both
the municipal and State domain is one factor (read more about this in chapter 5). Another contributing
factor to the assessment of the postion is without doubt the EA activities described at national level (see
chapter 5.3). The relationship between the streamlining potential and the technological preconditions
can be illustrated as in figure 13. The curve indicates the service level towards the citizens.
24
Accenture, http://www.contactomagazine.com/egovernment0529.htm
Page 47 of 112
The first level of maturity is a simple website. There are lots of these around in the public sector. This is
a static collection of pages, focused on the department or division, perhaps some downloadable forms
and some phone numbers. There is not much at this level which changes the nature of a citizen or
business interaction with the public.
The second level of maturity – online interaction through portals, simple forms, and search engines – is
often referred to as online government. The big step up here is the addition of transaction based services
in an effort to provide real value to the citizen. The focus is on the department and its business.
The third level of maturity – transactions, delimited self-service solutions – is called integrated
government. At this level we have moved away from individual, department-based transactions and
toward interactions that bring multiple processes together in a meaningful way. The big step up here is
the adding of end-to-end electronic transactions which is fully integrated into the back office systems
and processes.
Figure 13: Maturity of eGovernment in services for citizens and businesses.
Source: http://www.oio.dk/files/whitepaper.pdf
168H
The fourth level of maturity – integrated online services across organizations – is often referred to as
transformed government. At this high level of service the eGovernment processes are operating in ways
that change the very nature of how government works. State CIO of Utah, Phillip J. Windley 25, shared
the following experience as an example of transformed government:
24F24F
For an example of what a level 4 service might look like, imagine a couple--John and Mary-starting a family business. They know that there are a lot of requirements that government
places on anyone who starts a business. The problem is that they do not know what these
requirements are, let alone have time to meet all of them. One evening after discussing their
plans around the dinner table, John and Mary go to their computer and visit the
www.utah.gov web site. There they select a life event consistent with their situation,
25
http://www.windley.com/docs/egovernment%20maturity.pdf
Page 48 of 112
“Starting a Business,” and fill out a series of easy to understand screens that gather all the
information necessary to satisfy government’s demands associated with starting a business
in Utah.
After going through this simple process, the information that John and Mary entered is used
to register their business name with the Department of Commerce, get an EIN from the IRS,
notify the Tax Commission that they need a sales tax number, sign them up for a business
license with their city, set up their unemployment insurance account at the Department of
Workforce Services and apprise them of any licensing requirements. Because of the design
of the www.utah.gov portal, Mary and John are able complete this transaction in a secure
environment choosing from a variety of payment methods. In a few minutes at home, they
have taken care of tasks that would have taken days of driving from place to place, filling
out the same information on numerous forms. This is a completely new way of interacting
with government. They interact with government in an integrated fashion, “online, not in
line,” 24 hours a day, seven days a week from the convenience of their homes.
Even though this example is taken from the US, it is still useful in order to gain an understanding of
how transformed government works. This example goes beyond the State government to include
services offered by local government and the federal government. Phillip sums up by saying: “one day
these services may even extend to include private services such as banks or real estate”.
From the description of these different service levels, I would assess Denmark to be at level three, i.e.
having an integrated government.
4.9 EA Maturity and measurement
Having established a firm eGovernment maturity level for Denmark, I will now proceed to analyze EA
maturity. This will give me an indication of how long an organization is in the process of establishing,
operating and/or gaining value from enterprise architecture.
While other measures, e.g. effectiveness measures and status measures, is set up to measure specific
aspects of enterprise architecture, e.g. the EA documentation, the models, definitions, principles and
other artefacts (or assets) making up the EA 26, it is, according to IAC (2005), important to assess the
EA program and other areas of how EA is being utilized within eGovernance and decision making.
25F25F
Herzum (2003) has identified five maturity levels (see figure 14) which he believes corresponds to an
organizations’ ability to deal with EA aspects. He lists explicitly five stages an organization has to go
through when working with EA. Herzum also acknowledges that these stages are introduced in
simplified form; in reality it is anticipated that it is difficult, if not impossible, to identify maturity
stages which 100% corresponds to the complex environment of any organization. In the following are
his stages described.
26
See appendix 8
Page 49 of 112
Optimization
Integration
Blueprinting
Classification
Inception
Stages
Figure 14. Herzum's maturity stages. Source: Peter Engelund, 2006
The first stage – the inception – involves an organization is recognized by being technology centric but
having no knowledge regarding EA benefits and not having a defined EA team.
The second stage – classification – involves that an organization will have acknowledged the need of an
EA, defined an EA team, identified simple framework, created management support and established
simple portfolio modeling, e.g. describing the IT portfolio.
The third stage – blueprinting – involves an organization will have established an EA program and a
basic governance process describing how projects can assist in the creation of the EA. Furthermore
reference architectures are being built and actively used to make what Herzum calls strategic decisions.
One of the missing links at this stage is a lack of that the whole organization not yet is working towards
the establishment of an EA.
The fourth stage – integration – involves having established an EA where alignment between the
business, information, technology and applications is created and structured in a usable form.
Furthermore, which is believed to be a good point of measurement, the EA should have a quality level
to the point of being able to outsource the development of applications.
The fifth stage – optimization – involves having a complete EA covering the whole organization, there
are plans for the architecture and business goals can be tracked down to individual applications.
Obviously, a complete toolbox to support the EA is also present.
The public sector of Denmark may be high in eGovernment maturity, but when it comes to enterprise
architecture maturity, do not go beyond the first stage, thus being immature in relation to EA.
4.10 Architecture Frameworks
In large modern enterprises, a rigorously defined framework is necessary to be able to capture a vision
of the “entire organization” in all its dimensions and complexity. To illustrate this, Schekkerman, wrote
a book about it and called it: “How to survive in the jungle of Enterprise Architecture” in which he
compares 15 different EA frameworks and supporting tools. Zachman points out that one of the most
Page 50 of 112
misunderstood concepts about his framework is that it is not a methodology. It does not prescribe how
to conduct EA. In 1997, he produced a list of six key elements that a framework should support:
• Simple to understand
• Comprehensive
• A language – in the sense that it enables you to consider complex concepts without having to
know all the technical terms
• A planning tool to aid you in your decision making
• A problem-solving tool which gives you the freedom to simplify without loosing the overall
picture
• Neutral – i.e. independent of tools and methodologies.
In selecting the frameworks to analyze, I will first describe my universe of discourse: the Danish
municipalities and the State. I hypothesize that the municipalities’ EA activities are not maturity while
the same are mature as far as the State goes. I have already concluded from analyzing the input from the
study survey report that many municipalities are not very mature in EA aspects. Mapping this universe
of discourse to Zachman’s list of key elements, the municipalities’ framework should at least be simple
to understand, be comprehensive and be a planning tool to aid the municipalities in their decision
making efforts. I believe the best fitted EA framework for this support, is found in Scott Bernard EA3
Cube framework and implementation methodology (see chapter 4.10.1).
As far as my other universe of discourse goes, the State, which consists of many actors (see chapter
5.4.2), will need to have a framework tool that basically fulfills Zachman’s all six key elements, but in
particular it have to contain a language, which enables all the actors to consider complex concepts
without having to know all the technical terms.
Each EA is different, reflecting the unique characteristics of the organization and its goals. But according to OMB's definition, all EA’s should have three major components: the "AS/IS", or baseline,
architecture, which captures the organization's current architecture; the "TO/BE", or target, architecture,
which describes the organization's desired architecture as designed to achieve strategic goals; and a
transition plan, which uses a phased approach to get from "AS/IS" to "TO/BE". An organization must
also have a structured process for managing change to its EA, which needs to change as the
organization changes—in a continuous process. In my search for this, I choose Jane Carbone’s IT
architecture Toolkit, as it is easy to synchronize the methodology amongst a team, it’s quick to read and
will push the right buttons. Getting the main public actors to read large text books is out of the question.
Once everyone grasps the methodology and the desired outputs, it is possible to introduce more
complexity to the enterprise architecture/strategic approach as necessary. Figure 15 illustrates how
these frameworks can be mapped to the two public domain areas: the municipalities and the State.
I will only brief summarize how an optimal framework for merging municipalities could look like
based on Bernard’s own framework. This I will do based on my own previous research within the area.
From the EA Toolkit, I will deal with the business needs of the State. The architecture framework and
an in-depth description of the implementation strategies for the State are beyond the scope of this thesis.
Page 51 of 112
EA3 Cube framework
The municipalities
The State
Figure 15. Mapping of architectures to my universe of discourses. Source: Own contribution.
I will, however, depending on my findings in the business needs, suggest ways to improve the
awareness, the propagation and the use of Enterprise Architecture in the State of Denmark through a
management program.
3
4.10.1 The EA Cube framework
Bernard’s implementation methodology identifies distinct lines of businesses which encompass five
sub-architecture levels and three common thread areas (see figure 9). The sub-architecture levels
address strategic initiatives, business processes, information flows, systems and services and
infrastructure. The three threads entail security, standards and workforce. The EA3 framework not only
recognizes the role of early architecture approaches that addressed data, applications and networks but
also recognizes newer approaches promoting strategic scenario planning, the value of business supply
chains and web-based services. This framework is mapped to the public sector at different levels. The
sub-architecture systems and services in particular exemplify how EA can link strategy, business and
technology components across the enterprise within a so-called “service bus” that provides a platformindependent common operating environment for IT systems and services. It is the standards thread
which ensures interoperability within the service bus by promoting the use of IT systems and services
based upon open standards/protocols and non-proprietary solutions.
Page 52 of 112
Figure 16. EA best practice framework for merging municipalities. Source: Own contribution.
As mentioned in the ‘Background of the thesis’, Bo Kristensen and I previously analyzed the merging
of the Danish municipalities. As figure 16 illustrates, the end result hereof was a recommendation of a
framework in support of the merging municipalities 27. As the reader probably recognizes, this
framework is based on Bernard’s EA3 cube but with a few important ratifications. First of all, the
starting point is from four different AS/IS views to one TO/BE view. Writing an EA management plan
for this is a complex and comprehensive task. Secondly, the TO/BE enterprise (i.e. the municipality) is
not only influenced (i.e. dependent) on external environmental factors originating from technical and
business oriented trends but also influenced by political decisions and the needs of the citizens. Third,
we added an extra functional area: The organizational structure. We summarized by saying: “This
structure has to be in place first and must take into consideration the business oriented demands the
municipality faces in the future. I would not be surprised to see if the same is the case when introducing
EA into the State domain. This I have not analyzed or made research on before, so this area of focus
will form the remainder of the study.
26F26F
4.10.2 The EA Toolkit IT Framework
In honoring the previous chosen EA definition (see chapter 4.1.2), our working EA definition in the
public sector must entail both a current and future state from an integrated strategy, business and
technology perspective. Carbone’s EA toolkit business framework (2004) captures this structure very
well. The rows represent a snapshot of where the enterprise is at a point in time. Bernard calls this
AS/IS and TO/BE. The columns describe the content outputs – data to be captured and addressed in IT
architecture (see figure 17). In the following I will describe the current state of EA through various
other information sources, such as the public domain by using my own research in the form of the
results of my study survey report and the Internet, Interviews and reports.
27
See appendix 4
Page 53 of 112
Content
View
Current State
Target State
Description
Analysis
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Figure 17. The EA toolkit business framework.
Source: Carbone (2004)
I have used Carbone’s EA as a national framework tool because of ease of use and it is applicable in
enterprises new to the discipline and concept of EA. Besides, this framework supports large and
complex structures, with changing environments, whereas Bernard’s much more precise and stringent
framework would be better suited for smaller enterprises such as a single municipality. Since I am
treating the whole public sector as one enterprise, I will continue with Carbone’s EA toolkit framework.
The description of the current state is a collection of facts. According to Carbone these facts should
entail:
1. Business strategy documents capturing the business purpose, e.g. mission statements, visions, and
goals
2. The history or culture of the enterprise
3. The business drivers that describe the major themes or motivational forces that impact the behavior
of the enterprise
4. Key constraints
5. The six W’s:
• What – what does the organization do? (e.g. sell VCR’s)
• When – describe any key events or historical changes that have or will have an impact on how
the enterprise operates
• How – In what ways does the enterprise conduct business? (Online research, retail sales centers
etc.)
• Who – The organization, its customers, suppliers, partners etc.
• Why – problems causing the business to work differently or a change in strategies and business
driver (why is this situation not working?)
• Where – the location of the enterprise, service departments, branches etc.
These six W’s resemble Zachman’s six questions in his two-grid framework (see appendix 2) but puts
them into a practical context. Carbone suggests other more general elements to be captured. Of these I
have selected those relevant for Denmark Ltd.:
• company size in annual revenue, expenses, and number of employees
• number and types of customers
• locations served and serving
• list of products and service, and quantities sold
• high level organizational structure and/or process flow
• current technology
Page 54 of 112
•
external interfaces
The analysis of the current state involves among other methods assessment indicators – factors used to
analyze the business current state data as collected in the previous step. Just like a thermometer they
provide a way to gauge a temperature of the business. Carbone suggests the following points as
assessment indicators:
• Stress points/risks
• Strengths and weaknesses
• Challenges
• Environmental factors
• Growth/cost containment opportunities
The description of the target state is about foreseeing the target state of the enterprise. According to
Carbone, there are two approaches to apply in describing this target state: the positive statements
approach or the visionary approach. The former includes asking this question:
How would the business behave if:
• Stress points were relaxed/risks mitigated?
• Weaknesses were addressed and strengths fortified?
• Challenges were resolved?
• Environment changes were accounted for?
• Growth/cost containment opportunities were leveraged?
The visionary approach allows me to describe the target state in more depth, and takes on an ideal
future view. In the ideal future:
• How will customers and suppliers interact with the enterprise?
• What would the future high-level business function flow look like?
• What key business information will flow through the process?
• What critical people, plans and skills will be in place?
• What critical support processes and structures will be in place?
• What key capabilities will enable the desired state?
It is a difficult task – and not always realistic – to describe the ideal future. Instead I will to capture all
the problems in the current state and see what the future looks like if they are overcome, thus taking on
the positive statements approach in describing the target state.
The analysis of the target state comprises the identification of significant business opportunities and/or
gaps to be addressed by IT architecture. Again, two approaches are suggested: The first approach
compares significant stress points, strengths/weaknesses, challenges, environmental factors, and growth
opportunities between the current state description and the target state description. The second approach
also compares the current and target state, then lists the differences as gaps, and finally reversing the
gaps as opportunities. Since this last approach will simplify the translation to infrastructure planning,
and it tends to result in less general, more specific opportunities for action, especially when analyzing
flows, I will choose the second approach in analyzing the target state of the State domain.
I will sum up this business view of the State domain in an integrated approach similar to figure 17, and
thus have a working list of key areas to be addressed with architecture.
Page 55 of 112
5. Description of the Current State
5.1 Introduction
The description of the current state contains just the facts. These comprise a business strategy (mission
statements, visions, goals etc.), the history or culture of the enterprise, the business drivers that describe
the major themes or motivational forces that impact the behavior of the enterprise and six key
constraints: 1) what, 2) when, 3) how, 4) who, 5) why and 6) where.
5.2 Business strategy documents
This section contains the business strategy documents, such as mission statements, goals and/or vision
of EA in the public sector.
5.2.1 Vision of the structure reform
First we need to define the vision the Danish politicians have set forth 28. They are the CEO’s of
Denmark Ltd. – the managers of “the public business”. The government has not been very open though
about declaring its vision and accompanying goals of the structure reform. A vision should be visible
and easily accessible to the population, but it is not. I have found a copy of the official agreement
document between the political parties of the structure reform, and in sentences extracted the vision of
the structure reform:
27F27F
The vision of the reform is to maintain and enhance a democratic governed public sector
with an established strong foundation for continued development of the Danish welfare
society.
5.2.2 Goals
The goals for realizing this vision is as follows:
•
•
Create sustainable units with a clear responsibility in delivering welfare services of utmost
quality to the Danish population
With the future larger municipalities more opportunities arise for improved task solutions and
for welfare tasks to be solved by the municipalities themselves. With more tasks placed locally,
the democracy will be strengthened due to an increasing number of political decisions made
locally. The democracy must be propagated, so the citizens will be actively involved with the
decisions. The municipalities must find new ways of involving the citizens and users in these
local decisions.
5.2.2.1 Strategy for digital strategy for the municipalities 29
If the vision of a coherent public sector with the municipal as the citizens’ main entrance to the public is
to be fulfilled, then this will demand a heretofore unseen co-operation and relationship across the
authorities. E-Governance will be the spearhead in this development. 30
28F28F
29F29F
28
http://www.im.dk/imagesupload/dokument/Aftale%20om%20strukturreform%20ny.pdf
http://e.gov.dk/uploads/media/Digital_Communication_in_the_Public_Sector_01.pdf
30
http://www.kl.dk/367274/
29
Page 56 of 112
Below is the municipalities’ vision of the digital activities of Denmark.
The e-Government vision is to systematically use digital technologies to introduce new ways
of thinking and transform organizations and work processes to improve the quality of
service and efficiency.
The digital goals for realizing this vision have also been set forth:
• E-Government should actively contribute to the development of the network society.
• The public sector should work and communicate electronically.
• The services of the public sector should be delivered in a comprehensive and customer-centric
way.
• The tasks of the public sector should be carried out where they are handled in the best possible
way.
5.3 The history of EA in Denmark Ltd.
On June 13 2003, the Danish Ministry of Science, Technology and Innovation published a ‘national
white paper 31 on enterprise architecture. After that a handbook on EA implementation 32 was written in
2004 and current EA activities are a virtual EA guide 33, a national EA repository 34 and a range of
reference models and patterns 35. The white paper has been prepared by a working group with
representatives from the state, the counties and the municipalities, and was commissioned by the
Coordinating Information Council.
30F30F
31F31F
169H
32F32F
3F3F
34F34F
5.3.1 Recommendations
The main recommendations are:
• The public sector – at agency level and at large – should take on a more active responsibility
for its own enterprise architecture.
• Government should create a joint enterprise architecture framework for the planning of government IT systems with a particular focus on securing interoperability.
• A pronounced effort to raise awareness spread knowledge and develops competencies with
regard to enterprise architecture, especially around joint government initiatives.
This recommendation calls for both a vertical (“at agency level and at large”) and horizontally (“joint
enterprise architecture framework” and “joint government initiatives”) focus.
5.3.2 Joint Enterprise Architecture Framework
The white paper suggests that the joint enterprise architecture framework at least contains the following:
31
http://www.oio.dk/arkitektur/publikationer/whitepaper
http://www.oio.dk/arkitektur/publikationer/haandbog
33
http://ab.oio.dk/arkitekturguide
34
http://ab.oio.dk/arkitekturbibliotek
35
http://ab.oio.dk/referencemodeller-monstre
32
Page 57 of 112
•
•
•
•
Joint coordination, including the establishing of a National Enterprise Architecture Committee
with reference to the Coordinating Information Council.
Common methodologies in terms of processes, concepts and description standards for enterprise architecture.
Common choices regarding standards and infrastructure, including usage of a common reference profile (e-GIF) and common architectural principles.
Common tools, e.g., by using shared databases and libraries of contract models, process descriptions, data definitions, software components and infrastructure patterns.
It emphasizes an increased focus on Enterprise Architecture and cross-governmental coordination efforts as essential elements for realizing the visions of eGovernment.
5.3.3 Principles
As a common architectural principle, the white paper recommends the Danish government to adopt a
service oriented architecture (SOA) model, in which IT-solutions are modularly designed services that
have well-defined interfaces to each other and to legacy systems. It is considered a basic principle in
SOA to organize components in layers that offers and uses
each other’s services. Web services are practical examples
of a service-oriented architecture implementation. KL
refers to SOA as Lego blocks. For instance IT solutions
have to be made up by “Lego blocks”, where each block is
equivalent to a well defined part of the overall workflow.
An IT solution for pension contains a form, a decision, a
payment calculation and a payment to the citizen. The
municipalities which want to manage the decision of the
case in regard to political issues can replace the ‘Basic
Register’ building block with another one and still have
a functional overall IT solution. This way of building IT is Figure 18. Illustration of how SOA works.
Source: 268Hhttp://www.kl.dk/it-strategi/
what KL – in a popular way – calls Service-Oriented
Architecture. In the same terminology – the popular way
– KL describes service user interfaces as buds on the Lego block that other IT solutions can hook up to
in order to request completion of certain tasks.
KL and KMD made an agreement about standardization and access to a number of municipal solutions
through service user interfaces into which SAP has been chosen as de facto future technical platform.
The process has already begun with reengineering all existing SAP modules to this architecture.
So now, more than three years after the Danish Ministry of Science, Technology and Innovation
published its white paper on EA, KL has finally come around to focusing in on this architecture as well,
thus fulfilling the white papers recommendation for architectural principle use: SOA. One may ask
himself why this has taken three years and one can only think of how far the Danish municipalities
could have been had the recommended architectural principle been integrated into KL’s IT strategy for
the municipalities and put into practice three years ago when it was recommended. Has the technology
not been here before? Yes! Has the market, i.e. the municipalities not been ready for it before? Maybe
not! Perhaps the need hasn’t been here before? It looks like the need has been here since June 2003
when the white paper recommended its use. Or is this simply an expression of urgency: now the
Page 58 of 112
municipalities are merging KL has to come up with a digital strategy for the municipalities in order to
take the heat of the pressure from the municipalities and the government. Whatever the motive or
reason for delay, it looks like SOA is finally here to stay.
Since this concept is here to stay, I will distance myself from the popular definition, and instead clarify
the concept of services more precisely. Depending on the level, this concept can be thought of
differently. At the conceptual level, SOA represents a model of loose-coupled applications working
together by exposing services to each other. At the business level, services are expressing data- and
function services that one party can offer other parties to use, e.g. businesslike terms. At the
technological level, SOA consists of a group of emerging standards that define protocols and creates a
loosely couple framework for programmed communication between different systems. At the physical
level, web services are a notion that describes a method which enables an application to be invoked by
other applications by receiving and sending data in standardized XML.
In itself, SOA does not prescribe any particular technical standards, even though vendors offer technical
solutions. The standardization process for web services standards takes place in various international
organizations like W3C, OASIS etc. I will not at this time pursue SOA and its effects any further as it is
beyond the scope of this study.
The white paper points out 5 core architectural principles:
• Interoperability
• Security
• Openness
• Flexibility
• Scalability
5.3.4 Structure
The architectural process should embrace the core principles. This process is illustrated in figure 19
with two sequential circles containing: The main architecture process and the implementation process.
In the first circle are the enterprise visions used to define business process architecture, then
information architecture, and then the technical architecture. This process thus defines the concrete
architectural principles, which are used in the second circle. This process consists of portfolio planning,
Gap analysis and implementation projects.
Figure 19. White Paper Structure. Source: Own contribution
Page 59 of 112
5.3.5 Guidance
A Danish National Enterprise Architecture Competency Community will be established. The National
IT and Telecom Agency (NITA) will act as facilitator and advisor, and host a number of municipal
services, online and offline. NITA will also serve the National Enterprise Architecture Committee. A
National Forum for Enterprise Architects will be established in collaboration with the industry and
academia, and will be designed as a community of practice.
To push forward the standardization work, NITA will present a first draft of the common reference
profile (e-GID, e-Government Interoperability Framework) soon after the white paper is published.
NITA will also produce a set of guidelines.
5.4 The business drivers
What drives the public sector or what are the motivational forces that impact the behavior of the
organization? According to the study survey report, 25% of the municipalities’ primary motivation for
participating in a joint municipal IT co-operation is economies of scale, 18,75% have synergy as
primary motivational factor while 18,75% have improved citizen service. It is interesting to note that
75% of the ones who have economies of scale as their primary motivation for business also thinks the
new joint citizen portal is indispensable.
5.4.1 Key constraints
Seen from the municipalities’ point of view they do not have influence on national legislation
regulating the use of IT in the public sector. When the OIOXML standard was introduced, all had to
adhere to it. However with the reform, the municipalities have a lot more influence on local issues than
before.
5.4.2 The six W’s
This paragraph describes the ‘who’, ‘what’, ‘when’, ‘how’, ‘why’ and ‘where’ issues of the enterprise.
5.4.2.1 Who?
The 13 counties in the country will be replaced by 5 regions. These will be led by a regional council
with 41 members. The regions do not have the right to impose taxes and are only allowed to deal with
tasks determined by law.
As a result of the task- and structure reformation decided by the Danish Parliament the number of
municipalities will change from 271 to 98 by January 1, 2007. There are 225 municipalities which are
merging with no change in boundary, 32 municipalities with unchanged boundaries and 14
municipalities that split up as a result of merging. 36
35F35F
With respect to the management and liberty of action of the municipalities, they will still be led by a
city council consisting of 9-31 members depending on the size of the municipality. They have the right
to impose taxes and are comprised of the municipal authority.
36
See appendix 7
Page 60 of 112
A clear and distinct distribution of the role- and responsibility is crucial for the realization of the vision
and the implementation of the EA program. The overall Digital Project E-governance create common
frames and support cross-cutting co-operation, but the responsibility for realizing concrete benefits
involves and commits the different authorities across sectors and authority levels within the entire
public sector. In comparison to the general development a number of fora and authorities have a certain
responsibility. These are listed below and split up in the three different areas 1) the municipal domain,
2) the state domain and 3) common fora, for the sake of maintaining an overview of the actors. In some
fora where several actors are represented from different places, I find it relevant to identify the meeting
frequency and its participants in order to more fully establish the view of the actors. Therefore these
two elements have been left out in the more permanent structures such as KL.
The municipal domain
Actor
Domain
Purpose
KL (The National
Municipal
Attend to democratic governed municipalities’ common interests
Association of the
and to be the centre for collecting, developing and distributing
Municipalities)
knowledge of the Danish municipal government.
KL
is
the
municipalities’
principal
interestand member organisation of the soon 98 new municipalities in
Description
Denmark.
• Attend to the municipalities’ common interests
Tasks
• Aid the individual municipalities in counselling and with services
• Ensure up-to-date and relevant information to the municipalities
Table 4. Municipal EA actor # 1
Actor
Domain
Purpose
Meetings
The digitization counsel of the
municipalities
Municipal
Promote the implementation of a whole
and coordinated digital governance in
the municipalities by participating in
carrying out and communication of
concrete projects.
According to
need – usually
3-4 times per
year
Description Established by KL
Participants A number of municipal- and administration CEO’s (at the moment: CEO for KL as chairman, 1 senior
manager, 4 city managers, 1 financial manager, 1 manager for the social area, 1 manager for the technical
area, 1 vice president of the City of Copenhagen, and 1 IT manager – all but a few from the municipalities
• Digital counsellors to the board of management at KL
Tasks
• Create common municipal standards and promote competition between IT suppliers
• Anchor and focus in on working with digitalizing in the municipalities by taking an active part in
prioritizing concrete initiatives and projects, and coordinates these, which to a greater extent has
focus on the organization, structure and management side than on the technical side of the
implementation
Actor
Domain
Purpose
Kommune
Municipal
To secure common digital solutions for the municipalities.
Holding A/S
Description 100% owned by KL. Kommune Holding A/S owns KMD A/S and Kommuneinformation A/S. It was
established in 2003 by KL to separate the politics and business aspects and as a linking element between
KL and KMD. It was also established because no single enterprise can provide solutions which fulfil all
the municipalities’ needs in a multiple supplier environment, and to ensure the free choice for the
municipalities.
• Ad hoc tasks such as the development and operation of a new BBR register, and standardising of
Tasks
municipal basic data.
Page 61 of 112
Actor
Domain
Kommuneinformation
Municipal
Purpose
To produce knowledge and solutions, which create value
for the municipalities, so administrative procedures can
act effectively, citizen oriented and in accordance with
legislation.
Description 100% owned by Kommune Holding A/S, which in turn is owned by KL.
• Deliver knowledge based solutions, which focus on efficiency of the internal workflows in the
Tasks
municipalities
• Securing that the citizens receive the best and legislative most correct service
• Supporting the municipal case workers in establishing an effective dialogue with citizens, politicians
and other areas of the governance through graphical and digital solutions.
Actor
Domain
KMD
Municipal
Purpose
To deliver IT and consultant services to the private and public
sector
100%
owned
by
Kommune
Holding
A/S,
which
in turn is owned by KL.
Description
• Developing self-service portals such as www.netborger.dk and www.e-boks.dk
Tasks
• To support the employees in the public sector at any time can respond to and manage
170H
Actor
Description
Domain
17H
Purpose
Meetings
Board of
Municipal
Govern the IT Contact N/A
management
Committee
Established in order to govern the contact to the IT Contact Committee
• Be a governing body of the IT Contact Committee
• Be the link between the IT Contact Committee and KL
Tasks
Actor
Domain
Purpose
Meetings
IT Contact
Municipal
To be the linking element between KL and
Committee
the municipal IT-departments
Established
as
a
link
between
KL
and
the municipalities
Description
• Send out information on IT related matters to the municipalities
Tasks
• Receive feedback from the municipalities
• Link between KL and the municipalities
N/A
The State domain
Authorities with certain responsibility for e-Governance are listed below.
Actor
Domain
Purpose
The Ministry of Finances
State
N/A
Description E-Governance is an integral part of the public administration policy and modernization of the public
sector among other things through the governments’ modernization program, which is on of the primary
framesets for coordinating initiatives for developing and streamlining the public sector.
Tasks
•
Work mainly with strategic aspects of IT, such as IT-strategy
Table 11. State EA actor # 1
Page 62 of 112
Actor
Domain
Purpose
The Ministry of Science, Technology and Innovation
State
N/A
Description The Ministry contribute through the governments’ IT policy and the State IT policy to the realization of
the government’s policy towards citizens, companies and the public sector. The Ministry is sphere
responsible towards the public sector for the technical development of which production of standards and
policies as well as the public information policy is a part.
Description
•
Work mainly with technical aspects of IT, such as IT-architecture
Actor
Domain
Purpose
Meetings
The State IT
State
Set the agenda for an offensive use of IT
N/A
Council
in the public sector
Participants All government departments at the level of management with the Ministry of Science, Technology and
Innovation with the IT- and Telecom Agency CEO as chairman
Tasks
• Contribute with initiatives for the governments IT-policy, so that the policy supports the development
of Danish society in the best way possible.
• The council should discuss State IT-policy and secure co-operation of common problem areas.
• Exchange of experiences, guidance and common solutions.
•
Organizational development and competence development.
Actor
Domain
Purpose
The National IT and
State
Ensure an optimal framework for IT and telecommunications and
Telecom Agency
conditions that will enable citizens, businesses and the public
(NITA)
sector to realize the network society
The
agency
is
part
of
Ministry
of
Science,
Technology and Innovation.
Description
Tasks
• Develop and implement initiatives within key areas of the Government’s IT policy strategy.
• As part of the Ministry, it provides input to the Minister and advises on IT related matters and
legislation concerned with telecommunications, communications and information technology.
• Assists in drafting policy proposals, bills and executive orders in co-operation with the Ministry’s
departments
• The agency assists in answering questions from the Danish Parliament and letters from citizens.
Actor
Domain
Purpose
Meetings
IT Architecture
State
To support a coherent and effective N/A
Office at NITA
use of public IT.
Description This office creates framework for and promote use of public IT architecture. This is realized by listing a
number of guidelines for IT system configurations, i.e. concerning user administration, information
architecture or demand on the technical infrastructure. It supports the governments IT policy with
concrete IT projects and IT-related knowledge and attach bond between the public and the private. This is
done for instance through the FESD (The Joint Public Electronic Case- and Document Handling) project.
This office further works as a co-operation partner in relation to a number of larger IT projects i.e. the
business portals www.virk.dk and www.skat.dk. It is a secretariat to the OIO-IT architecture committee
along with responsibility within co-operation with sector standardized committees of IT architecture and
IT standardization at sector level.
Participants
N/A
Tasks
• Development of IT architecture
• E-governance
• Operation and development of the FESD standardization, including participation in the Steering
group (STS)
• The common public standardization catalogue (the OIO catalogue)
• Knowledge centre for software
172H
173H
Page 63 of 112
Participants
Tasks
Actor
Domain
The State IT forum
State
Purpose
Meetings
A committee under the State IT counsel
Monthly
to address technical issues
The CIO’s for each government department. The Ministry of Science, Technology and Development give
counsel and point out the chairman for the State IT forum.
• Discuss technical problem areas originating from the State IT counsel.
• Discuss and review cross problem areas regarding the States use of IT starting from technical,
organizational and administrative conditions attached to procurement and usability of IT.
• Reports to the State IT counsel.
Common fora
Actor
Description
Participants
Domain
Purpose
Meetings
The
Common fora
STS plays the most central role for carrying out enterprise
Steering
architecture and e-Governance in Denmark and other joint
Once a month
Group
national initiatives.
(STS)
The Steering Group plays a very active role in the establishment of the digital task force’s tasks. STS
governs Project e-Governance and the digital task force (the ‘Taskforce”).
Head of the department of The Ministry of Finance, The Ministry of Science, Technology and Innovation,
The Danish Ministry of Economic and Business Affairs, The Danish Ministry of Domestic Affairs and
Health, the CEO of KL and TADR (The Association of the Danish Regions).
•
Tasks
Table 17. Common Fora EA actor # 1
Actor
Domain
Purpose
Meetings
The digital taskforce
Common
To promote the switching-over to eN/A
(the “Taskforce”)
fora
Governance across the public sector
Description Even though the Taskforce is physically located in the department of Finances, it is organizational subject
to STS. Among other projects, the Taskforce has worked with digitizing communication between several
public authorities also better known as the ‘e-Days’. This involved a large campaign with the aim to get
the Danish population to use the public digital self-service solutions. It acts as a technical secretariat for
the Steering Group STS.
Participants Consists of approximately 12 people inpatriated from the Danish Ministry of Finances and the municipal
organizations (KL and the Danish Regions). Inpatriation takes place from other departments and
government agencies according to the need.
Tasks
• Brings authorities together and act as a catalyst for solutions in transverse coordination problems in
the digitalizing process.
• The Taskforce must initiate, support and coordinate the development of e-Governance in Denmark.
Actor
Domain
The Coordinating Information
Committee
Common
fora
Purpose
Meetings
Secure a coordination and
N/A
development of a common IT policy
within the public sector
Description This committee has been formed by The Ministry of Science, Technology and Innovation.
Participants The Ministry of Science, Technology and Development, the digital task force, The Ministry of domestic
Affairs and Health, CPR-office, The Ministry of Economic and Business Affairs, KL, County Counsel
Association, The national IT and Telecom Agency.
Tasks
• The committee will together with the digital task force support the implementation of central
initiatives decided upon by the board of Project e-Governance
• The committee will contribute in securing public development and implementation of standards and
tools necessary in realizing the potential in public IT investments
Page 64 of 112
Actor
Domain
Purpose
Meetings
IT-Architecture
State
Follow-up on the white book on IT
N/A
Committee
architecture
Description Technical committee with reference to The Coordinating Information Committee
Participants All Ministries are represented at local CIO level. The Ministry of Science, Technology and Innovation is
chairman and offer together with The National IT and Telecommunication Agency secretariat aid to the
State IT Council.
Tasks
•
The committee coordinates its own activities with the data standardization committee
•
Secure a context, prioritizing and progression in the work with a common IT architecture framework
•
Give recommendations on the use of standards
•
Contribute to the development of joint concepts, principles, methods and tools for IT architecture
•
Facilitate sharing of knowledge and experiences concerning IT architecture
•
Provide assistance and counsel to the actors in the decentralized processes concerning IT architecture
•
Take part in securing access to relevant competences for the authorities
Table 20. Common for an EA actor # 4
Actor
Domain
Purpose
Meetings
Data Standardization
Common fora
Follow-up on the white book on data
N/A
Committee
standards
Description Technical committee with reference to The Coordinating Information Committee, formerly known as the
XML committee.
Participants All Ministries are represented at local CIO level. The Ministry of Science, Technology and Innovation is
chairman and offer together with The National IT and Telecommunication Agency secretariat aid to the
State IT Council.
Tasks
•
The committee coordinates its own activities with the IT-Architecture committee
•
Give recommendations on the use of data standards
•
Contribute to the development of joint concepts, principles, methods and tools for data standards
•
Facilitate sharing of knowledge and experiences concerning data standards
•
Provide assistance and counsel to the actors in the decentralized processes concerning data standards
•
Take part in securing access to relevant competences for the authorities
Table 21. Common fora EA actor #5
These three different views of the actors, the municipal domain, the common fora and the state domain,
can be summarized in figure 20 which gives an overview of the actors on the stage as well as their
inter-relationship.
To ensure quality and consistency of figure 20, it has been verified several times by Peter Gorm
Hansen, CEO of KL, by EA-specialist Kristian Hjort-Madsen 37, as well as by IT-architect Martin
Dohn 38.
36F36F
37F37F
The Ministry of Finances are closer to the middle than The Ministry of Science, Technology and
Innovation. The former work mostly with strategic aspects of IT, such as IT-strategy, whereas the latter
mostly work with the more technical issues, such as IT-architecture. According to Martin Dohn, IT
architect at the Ministry of Domestic Affairs, when carrying out enterprise architecture and egovernance in Denmark some fora are more relevant than others. STS plays the most central role for
this purpose and other joint national initiatives. Other players in this group of central players are the
digital task force and The National IT- and Telecom Agency (NITA) with its IT Architecture office. At
the other end of the scale, there are “soft” fora which are characterized by being what I call a
37
38
Kristian Hjort-Madsen, Enterprise Architect, The Ministry of Finances
Martin Dohn, IT architect, The Ministry of Domestic Affairs
Page 65 of 112
decentralised player. This involves providing input to other public agencies. These fora comprise the
ITA committee and the coordinating information committee.
In the process of producing figure 20, I have identified a few problems with the actors. As I said before,
some actors are more relevant than others. From several sources, every issue that ends at the “desk” of
the Coordinating Information Committee does not go any further. It is stranded here. During interviews
with XX and YY who independently of each other described this actor as an extremely passive partner I
learned that nothing really goes on in this committee: “Nothing happens here, and if an issue or
initiative is brought up from the IT-Architecture committee or Data standardization committee, it stops
at the Coordinating Information Committee.” Furthermore STS often just “by-passes” this actor and
goes directly to the ITA and Data committees. Besides being very ineffective, this mix of strong and
weak actors creates what I call islands in the State. The Coordinating Information Committee does not
communicate with STS and vice versa. There is a missing link here. I will deal with this whole issue of
common fora much more in phase 9, the EA management program. Commenting on this figure, XX
mentioned that Denmark is not geared for EA due to sluggishness
Figure 20. E-Governance overview of the three dimensions in Denmark. Source: Own contribution
in the public sector. This is exactly what XX municipality also pointed out from the study survey report,
when asked what could be the greatest obstacle for joint municipal IT co-operation. Their opinion
carries weight into the discussion, being one of the leading EA municipalities of Denmark. Mr. XX
Page 66 of 112
pointed out that Denmark is known for this wide spectrum in the middle – which I call ‘common fora’ –
having participants from both the municipal and State domain. He said: “This is one of our forces and
has become known as ‘the Danish model’ in other countries.” This I have indicated in the figure by the
horizontal arrow.
On the municipal domain side, KL is of the general opinion, that IT solutions must be propagated by
making it attractive for the market itself to deliver what the municipalities need. And the municipalities’
needs must be formulated as open standards for digital process flows which several suppliers will be
able to fulfill. Normally I will not show these suppliers of IT in figure 20, but since KMD is owned by
KL and is one of the main suppliers of IT solutions to the municipalities, it is included. An important
problem in the municipal domain have for many years been the development and sustainability of many
different systems. This is particularly relevant now, with most of the municipalities merging these
years. This has created the so-called silos in the public sector. I will also deal more with this issue in
phase 9, the EA management program.
As earlier mentioned Denmark is faced with a great restructuring of the entire public sector these years.
This will ultimately take effect by January 1, 2007. The structure- and task reformation suggests two
overall consequences: 1) restructuring of the physical boundaries of the municipalities and the creation
of new regions replacing the old counties and 2) reallocation of tasks between the State, the regions and
the municipalities. These tasks will be dealt with in the ‘what’ section of this chapter.
5.4.2.2 What?
The ‘What’ defines what the enterprise does? Figure 21 illustrates the three EA dimensions in the
public business model of Denmark. This elucidates the processes in the execution of the tasks as well
as clarifying the underlying infrastructure that will support these processes. The tasks comprise three
different management areas grouped in four task areas. The three management areas are:
1. Customer Relationship Management
The management of the contact to citizens
and companies.
2. Production Management
The management of the production of
public goods and services.
3. Administration Management
The management of the internal
administration in authorities and
institutions.
The three management areas facilitate four task areas.
These four task areas are:
1. Citizen and company contact – this entails Figure 21. EA dimensions of what the organization
communicating information of public do. Source: Denmark Ltd., KMD
goods and services to and from citizens
and companies and an overview of the individual level of involvement in relation to the
public domain.
2. National authority production – this entails law-oriented tasks like the social task, employment task etc. These tasks are characterized in that only public authorities can solve these
tasks.
Page 67 of 112
3. Service production – this entails childcare, school, elderly care, roads, parks etc. These are
tasks the public authorities to a degree can influence themselves and outsource the tasks to
private enterprises.
4. Internal administration – this entails tasks necessary to support the production of public
goods and services such as payrolls, staff, economy, procurement, logistics and management
information.
The internal administration is what Porter 39 refers to as the supporting activities to the primary
activities. The division of the production management into the national authority production and the
service production reflect how the public business must balance between supply and demand. The
national authority production occurs within a centrally agreed framework, i.e. legislation. The service
production tries to meet the demand of the citizens. According to Allan Vendelbo 40, CEO of the
Association of City Managers and former city manager of Ballerup municipality, the effectiveness
benefit is to be found in the Service Production. He talks about efficiency improvement, quality
development and competence development as the result of using new technology within the municipals.
He gives an example:
38F38F
39F39F
“Let’s say I as a leader of the municipal walks up to a social assistant and tells her that I
think she is a key worker in our organization and therefore I will empower her with a
handheld computer which can make her administrative work easier. Herein lies a
recognition and appreciation for her work and this creates motivated employees, who in
turn deliver better quality. But we cannot just give this device to her without any
introduction and instruction in how to use it. And herein lays the competence development,
which in turn gives her satisfaction, thus creating motivation while being very efficient.”
I agree with Allan Vendelbo that the efficiency improvement for the municipals mainly is to be found
in the Service Production. On the other hand, it is most likely that this improvement for the State is
found in the National Authority Production, wherefore I will deal with both sides of the Production
Management.
To the business model I add the sector levels (the
green and red vertical columns). A sector is a group
of companies, interest groups, public authorities
and institutions contributing to developing and
delivering a set of related products and services to
the citizen. This could be the educational sector, the
labor market sector etc.
The tasks in a sector are supported by communication to the citizens, companies, authorities,
institutions and internal administrative tasks. This
means that some sectors are primarily focused at the
National Authority Production, while others
primarily focus on the Service Production. This
National Authority related
means that sectors comprise all three management
Sector
areas as well as the main four tasks in the business model.
39
40
Service related Sector
Porter, Competitive advantage, 1998
Denmark A/S p. 57
Page 68 of 112
5.4.2.3 The State tasks
The State will continue to manage the overall coordination on a number of areas but will also take upon
itself new tasks. From the municipalities the State will take over assessment of taxes. From the counties
the upper secondary school, higher preparatory examination and other youth educations, part of the
road network and the overall environment and planning tasks. There will be 5 regions established to
supervise the municipalities. Besides this, a number of non-concentrated state institutions will be
established with the aim to solve the States’ regional tasks concerning taxes, education, employment
and environment.
Regional tasks
The tasks carried out by the regions include the health services, regional development tasks and the
operation of certain institutions within the social and health area.
Municipal tasks
The current tasks of the municipalities involve roughly all tasks close to the citizens. These include daycare institution, public schools, home helper service, rest homes, libraries, culture and leisure time and
environment, technical areas and urban planning. The tasks can be divided into those that are few and
complex and those which are many and simple as can be seen from figure 22.
The few complex tasks
Heart-transplantation
Forced removal of children
Schools for deaf/blinds
Integration
Public schools
Gymnasium
Twisted ancles
In-home service
The many simple tasks
Figure 22. Example of simple and complex tasks. Source: KMD
5.4.2.4 When?
The ‘when’ indicates any key events or historical changes that have or will have an impact on how the
enterprise operates. The most obvious is the current structure- and task reform that will take effect as of
January 1, 2007. For some it will have great impact on how the business is run. This is especially
relevant for the municipalities merging. All, however, will be affected by it, due to the reallocation of
tasks (see the ‘what’ section in this chapter).
5.4.2.5 How?
The ‘how’ indicates in what ways the enterprise conduct business, e.g. through online research, retail
sales centers etc. One of the primary ways the State conducts its services to the citizen is for the greater
part related to online self-service tools on the Internet.
Page 69 of 112
Denmark.dk is Denmark's official Internet face to the outside world. The portal, which is produced for
the Ministry of Foreign Affairs, is hosted by the National IT- and Telecom Agency. Private and public
content providers are collaborating on producing the content sections, which are being co-ordinated by
editorial staff at the National IT and Telecom Agency.
As a part of the structure reformation the two main public portals in Denmark, www.netborger.dk (KL
and KMD as developer) and www.danmark.dk (VTU 41 and The National IT and Telecom Agency as
developer) will close by January 1, 2007, and will be replaced by www.borger.dk which will then act as
the single entry point for the citizens to gain access to public information and services online. The
reason for establishing this new portal is due to the fact that many citizens request only one single entry
point to the public domain.
174H
175H
40F40F
176H
www.netborger.dk
The portal www.netborger.dk is owned by KL, The National Association of Communities 42. KMD 43
has developed it and operates the vast spectrum of the portal’s self-service solutions. The portal is
known for the latter. Assisted by electronic calculations, intelligent application forms and guides you
can save both time and money on this portal, which you would otherwise have spent if you went to the
local municipality. The portal creates the connection to the municipality in which the citizen lives. In
practice, this means that when a citizen fills out an online form it is redirected to the relevant
municipality which subsequently will process the request.
17H
41F41F
42F42F
According to KL 44 the portal is only a supplement to the information found on the municipalities’
websites. Therefore you can find ‘Netborger’s solutions on both the municipal website as well as on the
shared portal.
43F43F
This dual – and redundant – place of taken care of public tasks could stir up confusion among citizens.
What is possible to do on www.netborger.dk and what can I do on my municipal website? If I am
moving or applying for extra child support where do I go? To the portal or the municipality’s website?
And can you do something on the portal that is not possible on the municipality’s website and vice
versa?
178H
www.danmark.dk
The portal www.danmark.dk is owned by The Ministry of Science, Technology and Innovation. The
National IT and Telecom Agency has developed it and it currently operates under their supervision. Its
object is to ensure that as many citizens as possible have access to utilizing Information- and
Communication Technology in a safe and secure way. Denmark.dk consists of seven different editorial
sections as shown in table 22.
179H
180H
41
Ministry of Science, Technology and Innovation
See ‘Glossary’
43
KMD: The largest Danish-owned information technology enterprise
44
http://www.netborger.dk/om_netborger.asp
42
Page 70 of 112
Editorial section of
www.danmark.dk
Description
18H
Information on IT and telecommunication of interest to Danish
citizens.
Gives an overview of the different bills and make them easily
accessible to all. Updated daily with new laws, bills,
departmental orders, circulars etc.
Gives an overview of the public Denmark. It contains all public
institutions and a number of semi-public and private institutions
with a description of contact info.
Gives an overview of news from the public domain. It could be
latest bills passed in parliament, news from the authorities,
distinctions or new public websites
Gives access to the same self-service solutions offered by
www.netborger.dk from KMD. Link to the different
municipalities’ websites.
Gives an overview of the different published books, pamphlets
and leaflets within the public domain – both on- and offline.
Gives an overview of the citizens’ rights and opportunities.
Written by specialist from different organizations and
authorities. Updated as soon as a new law is passed.
IT-citizen
The law
Authorities
News
Self-service
Publications
What you need to know
182H
Table 22. Overview of the website: www.denmark.dk. Source: www.denmark.dk
183H
184H
So today there are not only two places the citizens can go to when communicating with the public, but
actually three: 1) the municipality website, 2) www.netborger.dk and 3) www.danmark.dk. Suspicious
of this undesirable spectrum of citizen-based entries to the public, a workgroup was established in the
fall of 2004 consisting of representatives from The Ministry of Science, Technology and Innovation,
IT- and Telecommunication, The Digital Task Force, The Ministry of Financial Affairs, The County
Council Association, KL and the Municipality of Copenhagen with the purpose of elucidating the
supply of public digital information and self-service functions towards the citizens and the citizens’
obstacles for using and demanding public digital communication. The outcome was a report called
“Digital communication between the public and the citizens 45” from June 2005, which was the
foundation of the decision of making one single entry to the public: www.borger.dk.
185H
186H
4F4F
187H
www.borger.dk
In order to realize the justification of the presence of this newly created citizen-based portal, one have
to understand the analysis and the results thereof that led to the decision of implementing this new
portal. The respondents were four typical user profiles:
18H
1)
2)
3)
4)
“The Uncertain”
“The Competent”
“The experienced”
“The professional”
45
http://videnskabsministeriet.dk/site/forside/publikationer/2005/digital-kommunikation-mellem-det-ofentlige-ogborgerne/kvalitativ_rapp.pdf
Page 71 of 112
The Experienced and The Professional primarily use the public digital self-service opportunities in a
two-way communication environment. The Competent primarily search for information, consequently
using one-way communication. The Uncertain has very little knowledge and use of public digital offers.
As can be seen from table 23, the strengths represent what could be considered “normal strengths” by
using an Internet based means of communication and information, such as always accessible, avoiding
lines, relieving human workforce etc. On the other hand the survey revealed that the citizens have a
difficult time finding and gaining an overview of the public digital services.
Strengths
Accessible around the clock
Fast – avoid standing in long lines
Accurate and updated information
Trustworthy information
Anonymous/impersonal (The Professional and
The Experienced)
Extra information – “that you did not look for”
Relieves the administrative employee
Weaknesses
Lack of overview
Missing standards (structure/layout)
Bad quality with specific public sites or self-service
opportunities
Inappropriate use of language
Too many codes
Bad search engine on some sites
Too much information about profile and value base
Lack of knowledge on digital signature
Impersonal – lack of social contact (The Competent
and The Uncertain)
Unaffectedly
Lack of referrals from other media
Missing links to other sites (public as well as private)
Lack of confirmation on complete tasks
Difficult to go back to previous page – and start page
Table 23. Strengths and weaknesses by using the public digital offerings. Source: www.borger.dk
189H
The citizens requested one single point of entry to the public domain. So we are down to two entry
points for the citizens after January 1, 2007: The municipality’s websites and www.borger.dk.
190H
It seems like a paradox that on one side the Ministry of Domestic Affairs stresses the fact that the
municipalities will be the citizens’ one single entry point to public information and services but on the
other hand the Danish Government, KL and The Association of County Authorities decide to establish
a common public citizen portal, www.borger.dk, as the first step towards a common public citizen
portal which will act as the center of digital communication between the citizen and the entire public
domain. 46
19H
45F45F
In www.borger.dk’s FAQ it is mentioned that it will not have any effect on the public websites from the
different municipalities, but will more act as a supplement to the different public websites. So if it is
only a distribution point of information with links to different municipal websites it does not live up to
its vision of providing digital communication between the citizen and the public domain.
192H
46
http://borger.dk/portal/page/pr04/borger_infosite/infosite/forside/spoergsmaal%20og%20svar
Page 72 of 112
The digital online www.borger.dk will be in effect by January 1, 2007 but by January 1, 2008, the
citizens will have their own personal page on the portal, called: “My Page”. Here they will have access
to personal information such as “My Taxes”, “MySU” and so on. 47 These services will cover public
needs across the entire public sector. The goal is to have the joint public citizen portal in effect from
2008 and all public self-service solutions implemented by 2012. 48
193H
46F46F
47F47F
So we have two citizen portals: 1) www.borger.dk and 2) the Development Project made by the
national steering group STS. Borger.dk is a temporary portal KL and VTU would like to do together. It
acts as a forerunner to the Development Project by STS and its presence is justified due to the fact that
there has to be a common portal by January 1, 2007, once the merging of the municipalities is a
realization. Besides this, a study reveals the citizens prefer one instead of two portals. By contract The
National IT- and Telecom Agency owns www.borger.dk.
194H
195H
Figure 23. General obstacles for contact with the public through the Internet 2006
49
48F48F
Figure 23 reveals the older you are, the greater the need for physical contact with the public consultants
which is the number one general obstacle for Internet contact with the public. The lack of immediate
and direct response is the second largest obstacle predominantly by citizens aged 20-39 years. The third
greatest obstacle constitutes concern of protection and security of information. The fourth highest is
“Others” which cannot be inferred further. The two least obstacles for citizens to contact the public
through the Internet are the service is not possible online or cannot be found and the use of the Internet
is too complex.
47
Telephone interview with Kristian Hjort-Madsen, Enterprise Architect, The Ministry of Finances
Telephone interview with Jacob Harder, Consultant, KL
49
http://www.dst.dk/upload/bef2006e_001.pdf
48
Page 73 of 112
Among the municipal CIO’s there are different opinions of this new common citizen portal. The
majority, 72%, thinks the portal is essential while only 6% think it is superfluous (see figure 24). The
latter consists of the more mature municipalities who have their own solutions for the citizens. As a
Figure 24. The city CIO's opinion of www.borger.dk.
Source: The study survey report (own contribution)
196H
surprise there is a whole of 22% who do not have an opinion on the matter. Many respond by saying
they have not seen the portal yet or do not know anything about it, indicating that the State – or
common fora – has not been effective in communicating the structure and content of this portal to the
municipalities or to the citizens. One municipality respond saying: “It is on one hand indispensable that
common public citizen solutions are developed and first and foremost standards for exchange of
information between the different public services. But on the other hand, it is crazy to try to direct the
citizens’ traffic in connection with public contact away from the municipal websites and into a central
one. By doing this you undermine the vision for having the municipality as a primary entrance to the
public for the citizen.
Seen from the citizens’ point of view, it is amazing how many that do not know that this important
public joint citizen portal will be launched by January, 2007. A whole of 77% do not know this.
A citizen study conducted by Computerworld and Userneeds 50 also reveals that 53% would like to visit
this portal once up and running. A whole of 40% don’t know. When asked if they know what the portal
contains a whole of 87% answered they did not know. When asked if they miss a central website where
they can have access to all their personal information and receive information about the public, 49%
responded affirmative to this question. 19% would only like to have access to their personal
information while 11% would like to only have access to a central website, where they can find
information about the public. A whole of 21% do not miss any of them. This could be interpreted as
they don’t care about the new joint citizen portal, since this is what it offers. Finally, when asked: “The
goal is to collect all personal information on the joint public citizen portal by 2012. Do you think this is
realistic?” a whole of 60% responded ‘Yes’ to this question, 14% ‘No’ and 26% ‘Don’t know’.
49F49F
50
See appendix 6
Page 74 of 112
Figure 25. The citizens' awareness of the portal. Source: Computerworld & Userneeds
5.4.2.6 Why?
The ‘why’ indicates problems causing the business to work differently or a change in strategies and
business drivers. The structure- and task reform certainly will influence the public sector, in particular
the municipalities in the form of additional tasks to perform in the future.
Future tasks of the municipalities
The new tasks of the municipalities involve health in connection with rehabilitation and prevention,
institutions within the social area, the environment and nature, special education, traffic and roads,
employment and citizen service centers.
The task- and structure reformation in Denmark is much more than a reformation of the municipalities.
It is a reformation of the entire public sector of Denmark. Roles and relations are changed for all
partners – the State, the regions and the municipalities. The goals of the reformation can be comprised
into five key elements 51:
1. The quality and the effectiveness within the public service sector are to be secured through larger
municipality units with sufficient financial and professional sustainability.
2. The citizen is to be put in the center. The solution of tasks must first meet the needs of the individual citizens instead of the systems’. Coherent tasks must, to the extent possible, be solved by the
same authority level.
3. The tasks must be solved at a decentralized level and as close to the citizen as possible.
4. The citizens must have only one entry into the public sector.
5. The local democracy must be strengthened and further developed.
50F50F
It is thus in the spirit of the task- and structure reformation that a number of tasks be transferred to the
level closest to the citizen: the municipality.
51
http://www.kl.dk/data/1494854/Den%20nye%20offentlige%20sektor%20-%20pjece%20jan.%202006.pdf
Page 75 of 112
A new start?
The structural reformation marks a new start for the municipal governance as the central authority in
the public sector. Basically, the municipalities are given four important roles:
First of all, the municipalities must solve problems seen from the citizens’ point of view – not from the
viewpoint of how the authorities most easily can organize their internal processes. This involves among
other things that the municipalities have to perform a completely new task when it comes to serving the
citizen. They will be the main entry for the citizens to the public sector and as such they have to guide
and serve the citizens, even though another public authority may have the responsibility for the
problem the citizens need to solve. This presents new perspectives for the municipalities being the entry
point the citizen always can turn to whenever a problem need to be solved or a question arises.
Secondly, the municipalities will be the central turning point in the public sector, when it comes to all
the tasks and services offered, which are in connection with people’s everyday lives. The responsibility
for the welfare policy will to a greater extend be turned over to the municipalities in areas such as
health, rehabilitation and special education. This brings the municipalities to the very front of the
welfare policy.
Third, to a great extent, it is up to the municipalities to realize the intentions of “the citizen in the
center”. This is also relevant in relation to the further development of the local democracy. The citizens
regard the municipalities in Denmark as the part of the public sector, where influence on political
decisions is most easily obtained. With the new conditions for this strengthened municipal governance,
it is natural to analyze what the demands and needs modern people claim in relation to citizen
involvement. It is an excellent opportunity to reconsider the involvement of the citizens within the
different municipalities, formulate a complete strategy for the involvement and build on the many
experiences they have already gained in this area.
Fourth, the municipalities will play a new role in connection to the new regions. The municipalities will
for the first time ever, gain an influence on a number of tasks and questions, which in the future will be
decided in each region by a contact committee, consisting of mayors and the chairman of the regional
council. With this added influence, the municipalities will get the opportunity to be the driving force
and leave important fingerprints on the regional politics. The prerequisite for this to happen is a close
coordination of different viewpoints and cooperation between the different municipalities within the
region.
5.4.2.7 Where?
The ‘where’ indicates the location of the enterprise. Even though a major reform is about to take place
in Denmark, most municipal buildings will not be closed, but instead turned into local citizen centers.
This is done in order to maintain the high level of service the municipalities are expected to honor in the
future. It is interesting to note, that the restructuring part of the reform is taking place in the
municipalities. But the State does not change at all. One could expect the State would change
correspondingly in order to assist the municipalities in performing their new tasks or in order to
streamline the IT initiatives among the greater geographic municipalities. Or as Peter Gorm Hansen,
CEO of KL, said it: “The State does not realize that the reform has a lot to do with the State itself”.
Page 76 of 112
6. Analysis of the Current State
6.1 Introduction
Analysis of the current state of EA involves among other methods assessment indicators – factors used
to analyze the business’ current state data as collected in the previous step. Just like a thermometer they
provide a way to gauge a temperature of the business. Carbone suggests the following points as
assessment indicators:
•
•
•
•
•
Stress points/risks
Strengths and weaknesses
Challenges
Environmental factors
Growth/cost containment opportunities
6.2 Stress points/risks
Some of the stress points/risks signifies what the worries are concerning the current business plan.
According to Carbone this could be significant decline or unexpected growth.
The process of the municipalities merging will most likely be a long and a slow one, i.e. expensive,
because there does not seem to be any support from the State. The state is not set up to support the
merging municipalities neither organizationally nor technically. Besides, the State has a serious
communication problem with the public: both the municipalities and the citizens. Most of these do not
even know what is going on with the new joint public citizen portal. I may have a hypothesis in this
thesis stating that the awareness, propagation and use of EA at State level is mature, but not much have
been published or communicated since the white paper came out in 2003. A recent study of SOA was
just published by the National IT and Telecom Agency. There could be much more focus on the portal
and its benefits. Another stress point is the immaturity of the municipalities with EA (see study survey
report). Maybe this is not a stress point for the municipal CIO’s but it ought to be!
6.3 Strengths and weaknesses
6.3.1 Strengths
One of the strengths which can be seen from the study survey report is that the municipalities learn a lot
from each other. This make a good ground for initiating joint municipal co-operations which already
has taking place among several municipalities. Another strength is the wide ‘common fora' with its vast
number of representatives.
6.3.2 Weaknesses
Here are some of the most obvious weaknesses:
• Citizens are being more demanding. They want quality and good service.
• IT initiatives in the public sector experience sluggishness. Some of the councils on the public
stage in common fora are “inactive”.
• The awareness of a joint public citizen portal is very limited.
• The issue of strategic use of IT is not on the board meetings in the different municipalities. 52
51F51F
52
Mr. Q, CIO for XX municipality
Page 77 of 112
6.4 Challenges
The Danish task force predicts the public sector will face severe pressure 53 from different sources.
These more general and overall challenges include:
• More elderly and fewer in the active workforce in the society
• Limited resources (financials means) available
• Increased international competition
• Demand of openness and minimal response time
52F52F
We are already witnessing some of these challenges today. When writing this thesis I have furthermore
discovered the following challenges:
•
•
•
Lack of communication from the actors primarily in the State domain and common fora to the
municipalities and the citizens
Sluggishness with joint public IT projects
Lack of proper organization to support the new and larger municipalities’ tasks
Unfortunately, these are not the only challenges. Locale and regional politicians are as a whole satisfied
with the new local governmental structure, but at the same time they criticize essential parts of its
content mainly directed toward financial matters. Their worries are primarily about two areas:
1. Short term: It will be more than difficult to finance the restructure of the Danish local
government areas, since no special financial means has been set aside for this enormous task.
2. Long term: There will be an increase in central governance and state control.
The chairman of KL, Erik Fabrin, states that it will be more than difficult to budget this year, not
because of the contract agreed upon between the Danish Government and KL about the financial
situation for the municipalities in the first year of the new municipal structure, but due to three big
reforms, taken in effect by January 1, 2007, and which has great consequences for the budget.
First, the municipalities take over a number of tasks from the counties, and even though the State covers
it, it is difficult to ensure 100% fairness of the distribution of the money, and in some municipalities it
is experienced that the amount given does not match the need.
Second, the Danish government has passed a resolution of equalization of resources between local
authorities redistributing billions of DKK between the municipalities. Some municipalities receive
money on this account, others will have to give back money, and then it will be missing in their budget.
Third, a harmonization has to take place at different levels of service in the new municipalities. Some
citizens will experience some improvements, others a degradation of the service.
“These three reforms will have a much greater impact on the individual municipalities’ finances than
the financial agreement between KL and the Danish Government. A few numbers will illustrate my
point: In the financial agreement it operates with a growth in the service expenses of a just below one
billion DKK or just below ½ %. For comparison due to the new tasks in the task reform the
53
See appendix 5
Page 78 of 112
municipalities are confronted with new tasks equivalent to approximately 23 billion DKK or a growth
of about 15%. 54”
53F53F
KL does not have any influence on how the money is distributed between the municipalities in
connection with the reforms. But they are joint responsible for the financial agreement for 2007. It is to
be kept within the spending policy goals, which changing governments have formulated in the 2010
plan. It is therefore subject to serious spending controls, which for the municipalities’ part only leaves
the possibility of maintaining the current level of service of the existing tasks, not leaving any room to
fix any discrepancies which the large reforms most likely will induce for the individual municipality.
Denmark is moving from a supply governed public sector towards one governed by demand. According
to Peter Gorm Hansen, CEO of KL, the reason for this is that “we taught our children in school to be
critical. They should be anti-authoritarian, ask questions and be active (Denmark Ltd, 2006). Before,
the citizens did not know what they wanted, but the development of the society has had the effect so
that the citizens are no longer satisfied with what other people are telling them and how things are.
They want freedom to choose. They are in a demanding mode. And if these demands are not met, the
citizen will go elsewhere, e.g. to private schools, private doctor’s clinics, private homecare service etc.
More than ever before, the municipalities are faced with an increase of demands of delivering high
service levels. Why? Because the citizens know what they want and they are demanding mode. But if
the State, who is not at close range with the citizens like the municipalities are, continues to run the “Iam-in-charge-here” policy, “a new dinosaur is born. The state has to co-operate with the municipalities. Otherwise things will go wrong (Peter Gorm Hansen, 2006). I totally agree with him on this
matter. Cooperation and communication between the State and the municipalities are essential not just
in order to survive, but also to create a coherent public sector.
This could be why Mr. Q said that “KMD’s new challenge will be to develop IT systems based on
citizens’ needs and not anymore on the caseworkers’ need in the municipality. For a very long time
KMD has been very good at developing customizable systems which met the exact need of the
caseworker in the municipality. Now the focus has changed, and it will be more pertinent than ever
before to focus on the citizen.” 55 It will be interesting to see how KMD will cope with this challenge in
the new municipalities in the years ahead.
54F54F
6.5 Environmental factors
The outcome of legislation regulating the use of EA in the municipalities is unclear. There this will not
be dealt with here.
6.6 Growth/cost containment opportunities
The State wants to create sustainable units with a clear responsibility in delivering welfare services of
utmost quality to the Danish population. It also wants to improve solutions of welfare tasks by placing
these with the municipalities, thus strengthening and propagating the democracy.
54
55
http://www.kl.dk/368619/
Interview with Mr. Q, CIO for XX municipality, 2. Nov. 2006
Page 79 of 112
7. Description of the Target State
7.1 Introduction
The description of the target state is about foreseeing the target state of the enterprise. As mentioned
earlier, Carbone suggests two approaches: the positive statements approach and the visionary approach.
I will use the positive statements approach, i.e. I will capture the current state problems and see what
the future state looks like if the assessment indicators in the ‘Analysis of the Current State’ are
removed. The target state thus embodies the achievement of mission and goals.
•
Stress points were relaxed/risks mitigated?
o The municipalities and citizens can in detail read about what to expect from the new
joint public citizen portal on the Internet and through produced pamphlets distributed to
them.
o The State will have a plan for backing up the “weak” municipalities.
o The State will organize itself in a manner that meets the needs of the new and larger
municipalities.
o The State will form a communication strategy towards the municipalities and the citizens
e.g. about the new citizen portal.
•
Weaknesses were addressed and strengths fortified?
o Fortify the strength where municipalities learn from each other, by nurturing a learning
environment through joint municipal IT co-operative initiatives. The State should be
behind this with the aid from KL and others.
o Fortify the ‘common fora’ by adding an Enterprise Architecture unit, thus making it
possible to streamline EA across the entire public sector and avoiding sluggishness in
joint public IT initiatives.
o Again the State will create a communication strategy to propagate awareness of the new
joint public citizen portal.
o The use of strategic IT will be taken up at board meetings as a fixed point on the agenda.
•
Challenges were resolved?
o The entire public sector is streamlined with a well-documented EA and SOA rooted in
an Enterprise Architecture Committee supporting long-lasting and sustainable principles.
o Again the State will create a communication strategy to propagate awareness of the new
joint public citizen portal.
o The State will co-operate with the municipalities through an Enterprise Architecture
Committee in the ‘common fora’ area with representatives from both the municipalities
and the State.
•
Environment changes were accounted for?
o Through legislation, there is a minimum set of requirements of suggested EA tools and
processes for the municipalities to work with. A central Enterprise Architecture
Committee will assist the municipalities in their EA efforts as needed.
Even though this goes against what the municipalities wish for – according to the study survey report –
I believe that the only way EA to a certain extent will ever be used in the municipalities is through
legislation, as we have seen with the OIOXML data standard implemented.
Page 80 of 112
•
Growth/cost containment opportunities were leveraged?
o To ensure utmost quality to the Danish citizens a central Enterprise Architecture
Committee will be formed to assist in securing quality to the citizens
o To aid the municipalities in finding the right solutions and to ease the carrying out of
welfare tasks, an Enterprise Architecture Committee will be established.
To comply with these entire challenges one ought to seriously consider aligning the public sector
according to the needs of the citizens and companies, in order to gain the great benefits an eGovernance is expected to produce. What we have seen in recent years and still see with the merging of
the municipalities is development driven by necessity. Why not be pro-active, starting with having the
end in mind, and organize the public sector in a long-lasting sustainable structure supporting the State’s
vision and goals to address these challenges in good time, thus avoiding fire extinction. This pressure
against the public sector now and in the years to come, calls for an even more integrated
implementation and exploitation of EA.
8. Analysis of the Target State
8.1 Introduction
This phase comprises the identification of significant business opportunities and/or gaps to be addressed
by IT architecture. The approach I use is to compare the current and target state, then lists the differences as gaps, and finally reversing the gaps as opportunities.
1. Compare the current and target states
2. List the difference
3. Reverse gap to opportunity
Here are the few gaps I have identified primarily for the State:
•
•
Communication
o Current: Neither the municipalities or the citizens know very much about this new joint
public citizen portal.
o Target: The municipalities and citizens can in detail read about what to expect from the
new joint public citizen portal on the Internet and through produced pamphlets
distributed to them.
o Gap: The level of information to the municipalities and the citizens about the new joint
public citizen portal is not satisfactory.
o Opportunity: The State will form a communication strategy towards the municipalities
and the citizens.
State support
o Current: Throughout the merging there does not seem to be any support from the State.
o Target: The municipal CIO’s have a common place from which they can receive technical and organizational aid through the merging period and beyond.
o Gap: There is no one to turn to for technical or organizational aid from the State domain;
especially relevant for the “weak” municipalities.
Page 81 of 112
o Opportunity: The State will organize itself in a manner that meets the needs of the new
and larger municipalities. Among other things, this will be done through the establishment of an Enterprise Architecture Committee.
•
Technical processes
o Current: The municipalities are considered immature in relation to the awareness and use
of Enterprise Architecture.
o Target: The municipalities are supporting Enterprise Architecture as part of their overall
IT strategy.
o Gap: No relation between IT and the business strategy.
o Opportunity: To create an environment supporting municipal issues regarding Enterprise
Architecture.
•
Organization
o Current: IT initiatives in the public sector experience sluggishness. Some of the councils
on the public stage in common fora are “inactive”.
o Target: There is no sluggishness in the public sector but a very streamlined organization
adaptable to change.
o Gap: Not all IT initiatives in the public sector are given the proper attention.
o Opportunity: Fortify the ‘common fora’ by adding an Enterprise Architecture unit, thus
making it possible to streamline EA across the entire public sector and avoiding
sluggishness in joint public IT initiatives and following through with these public IT
initiatives.
•
Key enabling capabilities
o Current: Increased competition from the private sector.
o Target: The State will co-operate with the municipalities through an Enterprise
Architecture Committee in the ‘common fora’ area with representatives from both the
municipalities and the State.
o Gap: There is no alignment of service levels in relation to business strategy across the
municipalities in serving the citizens.
o Opportunity: Create a strategy for service alignment in relation to municipalities’
business strategies through an EA committee.
•
Citizen-centric development
o Current: The suppliers of IT have for many years been used to develop systems for the
case worker in the municipality, not for the citizen.
o Target: The suppliers of IT are very good at developing customizable systems which
meet the exact need of the citizens in the municipalities.
o Gap: There is a lack of developing IT systems with the citizens’ needs in mind.
o Opportunity: Choose IT suppliers who will develop IT systems with the citizens’ needs
in mind. Conduct quality assurance in order to maintain consistency and relevancy in
relation to the citizens’ situation. This calls for a need of uniform technical demands of
system layout, user interfaces etc. so the citizen will see the same whether he is in the
central administration, the citizen centers located in the small villages or on the joint
public user portal on the Internet.
Page 82 of 112
8.2 Integration
The ability to relate the output of one cell with the output of other cells is fundamental to Carbone’s
Toolkit. I have illustrated this in figure 26 to show how the business framework outputs are interrelated.
This presents a working list of key areas to be addressed with architecture.
Content
View
Description
Analysis
Key facts
Assessment Indicators Result
No formal mechanism to integrate
growth opportunity in integrating EA
EA initiatives across the public
initiatives and developing citizen-centric
sector; not much experience in
systems could enhance the maturity of
Current State
developing systems and services to
eGovernment and enhance the service
citizens; borger.dk is not very well
level offered to the citizens
known
Reverse Assessment Indicator
Target opportunities
Citizens can take care of ALL their
Establish an Enterprise Architecture
Target State
needs on the portal; the public
Committee to communicate, coordinate
domain has a streamlined mature
and facilitate EA in the public domain
eGovernment setup
Figure 26. Interrelationship between output views. Source: Carbone (2004)
It is apparent that something is missing in the structure. I will in the following respond to this need with
the management program. This is the first issue the management program must deal with.
Page 83 of 112
9. EA Management program
9.1 Introduction
This EA management plan is also sometimes referred to as business transformation or EA implementation. This plan simply states how to move from your current view of EA to the future view. The
neXus 56 provides enterprise modeling and knowledge management capabilities to support business
innovation and transformation programs as can be seen from figure 27. The colored areas indicate the
areas of my focus in working out this thesis as seen from the municipalities and the State’s view.
5F5F
Figure 27. Business Transformation Overview (Source: http://www.ndyn.com/)
197H
Having described and analyzed the current and target state of the State of Denmark and its municipalities, there is a call for an improved organizational structure supporting the rapid change of
environment, which is especially relevant during these years of the municipal reform. I have done some
OMB
CIOcouncil
AIC
Figure 28. Extract from EA actors in the US
research with foreign government structures which are a little more mature than the Danish one to see
how they are structured. I found the US structure very interesting (see figure 28). This has been done to
see if there is anything we can learn from them. The Architecture and Infrastructure Committee (AIC)
reports to the CIO council. This council reports to the Office of Management and Budget (OMB)
department. Representatives of this last department participate in both AIC and the CIO council. The
56
Providing commercial solutions to Knowledge Management, http://www.ndyn.com
Page 84 of 112
US EA program is a lot more streamlined than the Danish one. This has inspired me to make an
important ratification to the existing structure in the ‘common fora’ (see figure 19) domain as can be
seen from figure 29.
Figure 29. Overview of the "new" public sector. Source: own contribution
There is a continued focus on public IT-systems are more interoperable and connected as a whole. The
problem is, as I see it, this will not happen BEFORE the organizational structure and will power is
present with the State. I will therefore recommend that the Coordinating Information Committee will be
replaced with a strong Enterprise Architecture Committee, having people from both “camps” (STS and
ITA/Data standardization committee) positioned in this committee. This will create a much more
powerful, broad and streamlined organization of the actors within the public domain ready to initiate
and sustain enterprise architecture plans for joint municipal IT co-operations as well as across the
different sectors. So, instead of having islands in the middle and silos in the municipal domain, a
streamlined common forum in the public EA organization aligning services across the entire public
sector and municipalities will be present.
Page 85 of 112
To conclude I would like to specify an actor profile for this new Enterprise Architecture Committee in a
similar manner to the ones created earlier (see table 24).
Actor
Domain
Enterprise Architecture
Committee
Common
fora
Purpose
Meetings
Securing and coordinating enterprise N/A
architecture activities both vertical
and horizontal within the public
sector.
Description This committee has been formed by The Ministry of Science, Technology and Innovation.
Participants Enterprise Architects represented from The Ministry of Science, Technology and Development, the digital
task force, The Ministry of Finances, KL and the County Council Association.
Tasks
• Receive council from ITA Committee and from the Data Standard Committee.
• Coordinate joint public EA efforts with STS done both horizontally across the public sector as well as
vertically within sectors.
• The committee will contribute in securing, that the public – through a joint effort between the
administrative levels – develop and implement standards and tools necessary to implement EA
• Aid the municipalities in their merging efforts and contribute with technical and organizational
expertise.
• More as needed…
Table 24. New State EA Actor #1. Source: Own contribution.
It is important that this new committee is a coordinating and a counseling one in order to function as
one of the main actors. It is likewise important that the representatives in this council both have the
technical and business aspects of the public sector as well as being some of the “big boys” in the field,
i.e. having influence and decision-making power in their own organizations to at least department CIO
level. I believe that Denmark with this powerful EA actor will much easier be able to realize the five
architectural principles suggested by the national white paper:
•
•
•
•
•
Interoperability
Security
Openness
Flexibility
Scalability
In fulfilling these principles the public domain will move to the next level of eGovernment structure
which in the end will ensure a higher level of service to the citizens. This will beyond doubt – if
implemented – increase the awareness, propagation, and use of enterprise architecture in the public
domain and will increase the EA maturity of the public domain.
Page 86 of 112
10. Conclusion, reflections, perspectives
10.1 Conclusion
The overall question of this thesis was trying to answer the following question:
I think I have answered the question to a certain degree. Due to the scope and complexity of the above
research question, I have had to balance my view at a certain abstraction level describing the enterprise
architecture activities within the public domain, and at the same time not go into any atomic discussion
or description of this area, so to loose sight of the issue at hand.
As for the municipalities, I have made a study survey report, from which I have analyzed the results and
can conclude that the Danish municipalities for the whole part not are at a mature level in relation to the
awareness, propagation and use of enterprise architecture. Even though 65% answered they have an EA
function, they do not seem to use it fully. The following witness to this fact: For the whole part there is
no EA framework, no EA measurement, no EA process, and no EA documentation.
As for the State goes, I made description analysis based on Carbone’s views: AS/IS and TO/BE. From
this and input from the study survey, I conclude that the EA intentions are present, but the structure is
not set up to support a full fledged EA program within the public domain.
10.2 Reflections
I have now finished this thesis, and looking back, I must say it has been a learning experience. Two
parts I have drawn into my thesis have very much caught the attention of public actors at all levels
among the EA actors on the stage: My study survey report and my figure showing the actors on the
stage. These two parts have also taken the longest time to produce properly.
As for the study survey report goes, I have personally contacted each of the 98 municipalities in order
to find out who the new CIO of the new municipality will be after the realization of the merging by
January 1, 2007. A name and an email of each have been acquired. This alone was a dragging task. My
questionnaire is targeted to the key person of the municipality: The CIO. He/she typically has his feet
well grounded in IT aspects and at the same time he is also referring to the management board. That
makes him the most competent person to answer any business-driven IT related questions in behalf of
his municipality. The questionnaire itself is database driven and all entries are saved in a central
database.
One of the greatest challenges working with the study survey was to define ‘Enterprise Architecture’ to
an audience not familiar with the concept. An iterative process started and having received feedback
from several test persons I finally chose to “translate it” into the Danish term: Business-oriented
Framework of IT. Since I did not know, if everyone understood this concept, I made sure to describe it
in the beginning of the study survey.
Page 87 of 112
I asked professionals in the area of business-driven IT in the municipalities to assist me in securing the
quality and relevancy of the questions in the questionnaire. I have done this to ensure the questions
could easily be understood by the CIO’s and are in accordance with the terms and concepts used by the
world of CIO’s. These professionals have carefully been selected partly based on guidance from John
Gotze and partly through general referral dialogues with municipal CIO’s. These people include:
•
•
•
•
•
Ellen Svenning, chairman of “The Association of Public CIO’s” and CIO of Ringe municipality
Hans Lembol, CIO of Slagelse municipality
Steen Deth, IT-architect at Gentofte municipality
Christina Bouras, consultant of digital strategy and development at Gentofte municipality, also
employed with Gentofte municipality
Preben Rasmussen Hoej, CIO for Birkeroed municipality
Their input has been most valuable. Telephone interviews as well as personal interviews have been
conducted with most of the above.
As for the ‘Actors on the stage’ figure, this has caught quite a stir among EA professionals. Many of the
actors in this figure have responded. Among others, I have emailed back and forth with the CEO of KL,
several IT-architects, CIO’s from various public departments as well as with the Ministry of Finances
and Ministry of Science, Technology and Innovation. Several told me that this figure is invaluable, and
they wonder why this has not been produced before. So do I!
10.3 Perspectives
I would like to draw EA, a joint municipal IT co-operation and the survey into different perspectives.
Why EA? I claim that one of the best ways to do public IT is doing EA with all the elements this
entails. I also believe that EA is one silver bullet and used in conjunction with another silver bullet,
SOA, this could be a very powerful tool to reach new heights of EA maturity of the public sector in
Denmark, especially if the organization first is in place supporting this infrastructure.
Why bother to make a joint municipal IT co-operation effort? Since the municipalities are given a
number of similar tasks to carry out with the reform, this joint effort could just be what they need in
order to provide greater service for the citizens at a lower cost. This is not something new. Several
municipalities are already actively engaged in joint municipal co-operative activities.
Why just make a survey to the municipal CIO’s? I have thought about other very relevant surveys:
•
•
•
One directed to the City Mayors (Da: borgmester)
One directed to the City Managers (Da: Kommunaldirektør)
One directed to the national public central actors
Conducting a survey for the city mayors would be interesting, since they are the politicians who outline
the visions of the municipality, and the visions drive the business which in turn drives IT. The emphasis
of the questions would be on which core values they emphasize that lay as foundation for carrying out
their policy program. Conducting a survey for the city managers is interesting, since they are the
leading public officers interpreting and executing the visions of the business. To exemplify, in response
to which is the greatest challenge in carrying out IT plans, CIO of XX and YY municipality, without
hesitation notes: “The board of management should have IT on the agenda”. A survey held for all city
Page 88 of 112
managers would most likely reveal any coincidental responses or if there is a pattern for omitting IT on
the agenda at board meetings in the Danish municipalities. Conducting a survey for the national public
central actors, will give us a better understanding of where we are heading as well as more in–depth
knowledge of joint national initiatives.
Page 89 of 112
References
Literature
Accenture, Users interaction with Government Websites:
http://www.contactomagazine.com/egovernment0529.htm
198H
a|EA, yearly congress 2005, Institute for Enterprise Architecture Developments:
http://www.enterprise-architecture.info/Images/Presentaties/NGI%20Congres%202005%20%20Waarde%20Enterprise%20Architectuur.pdf
19H
Amadei, Bernard (2004). Department of Civil, Environmental, and Architectural Engineering,
University of Colorado, Boulder, Engineering for the Developing World – Challenges and
Opportunities, statement by Albert Einstein (slide 28): http://www.ewbjsc.org/Files/Amadei_Presentation.pdf
20H
Analysis of the joint public citizen portal performed by KL (June 2006):
http://www.kl.dk/_bin/184123ba-dbc8-4711-aea6-b144a8a3186b.pdf
201H
Armour, F., Kaisler S., Liu S. (1999). Building an Enterprise Architecture Step by Step, IT Professional
1(4): 31-39, 1999.
Armour, Dr. F. Kaisler, Dr. S. Getter, J. Pippin, D. (2002). A UML-driven Enterprise Architecture Case
Study. IEEE Proceedings of the 36th Hawaii International Conference on System Sciences.
Avison, D. E. and Wood-Harper, A. T. (1990). Multiview: An Exploration in Information Systems
Development. New York: McGraw-Hill.
Bernard, S. A. (2004). Introduction to Enterprise Architecture, Author House, September 2004, ISBN:
1418498084.
Buchanan and Soley 2002, Aligning Enterprise Architecture and IT Investments with Corporate Goals:
http://www.bptrends.com/publicationfiles/META%20OMG%20WP%201-15-03.pdf
20H
Burk, Federal Enterprise Architecture Program Management Office, Sept. 2006:
http://egov.vic.gov.au/index.php?env=-innews/detail:m1113-1-1-8-s:n-723-0-0-203H
Carbone, Jane: IT Architecture Toolkit, Prentice Hall (2004), ISBN: 0131473794.
Carr, Nicholas G. (2003). IT Doesn’t Matter. Harvard Business Review, May 2003.
Carr, Nicholas G. (2003). Does IT Matter? Information Technology and the Corrosion of Competitive
Advantage, Harvard Business School Press (April 2004), ISBN: 1591394449.
Christiansen, Peter Engelund (2006). IT University of Copenhagen (Master Thesis):
http://www.easurvey.org/academicreport.htm
204H
Page 90 of 112
Chief Information Officers Council (1999). The Federal Enterprise Architecture Framework, Version
1.1.
Chief Information Officers Council (2000). Architecture Alignment and Assessment Guide, Chief
Information Officer Council.
Chief Information Officer Council (2000). Capital Planning and IT Management Committee, Smart
Practices in Capital Planning.
Chief Information Officer Council (February 2001). Federal Enterprise Architecture Version 1.0, Chief
Information Officer Council.
Chief Information Officers Council (2001). A Practical Guide to Federal Enterprise Architecture.
Chung, H., M., & McLeod, G (2002). Enterprise Architecture Implementation, and Infrastructure
Management. Proceedings of the 35th Hawaii International Conference on System Science.
Clinger-Cohen Act of 1996 (1996). Public Law 104-106, section 5125, 110 Stat. 684.
Denmark Ltd., KMD (2006). A discussion of Denmark as an Ltd company:
http://www.kmd.dk/F2FDC4B5-FF9B-42B8-9FAE-57B884F42B4B.W5Doc?id=58EEF799-37D046C4-9AA4-7306AFAF033F
205H
E-Governance in DK assessed by KL (2006):
http://www.kl.dk/_bin/731f15e5-2984-4697-a214-a42dccd5c02f.pdf
206H
Institute For Enterprise Architecture Developments (IFEAD): http://www.enterprise-architecture.info/
207H
Field, A. (2005). Research Methods II – Design a questionnaire:
http://www.sussex.ac.uk/Users/andyf/teaching/rm2/projects3.pdf
208H
Gartner's hype cycle. Source: Gartner's hype cycle. Source:
http://www.gartner.com/DisplayDocument?doc_cd=130115
209H
General obstacles for contact with the public through the Internet 2006, Denmark’s Statistics:
http://www.dst.dk/upload/bef2006e_001.pdf
210H
Gurpreet S. Pall, Microsoft Architectural Frameworks, 2005, Microsoft Corporation:
http://download.microsoft.com/documents/australia/MSDN/RAF_2005/GurpreetMicrosoft_Architecture_Frameworks-2.ppt
21H
Gøtze, John (2005). Maturity of eGovernment. Slide from John Gøtze’s teaching of EA, Nov. 2005.
Handbook on EA implementation: http://www.oio.dk/arkitektur/publikationer/haandbog
21H
Hasselbring, W. (2000), "Information system integration", Communications of the ACM, Vol. 43 No.6,
pp.33-8.
Herzum, Peter (2003). Applying Enterprise Architecture, Executive Report, Vol. 6, No. 3.
Page 91 of 112
Hirvonen, Ari P. & Pulkkinen, Mirja. (2004). A Practical Approach to EA Planning and Development:
The EA management Grid. Business Information Systems, Proceedings of BIS 2004, Poznan, Poland.
http://www.titu.jyu.fi/julkaisut/muut/Hirvonen_Pulkkinen_2004.pdf
213H
Hjort-Madsen, K. & Ravn (2004). ICA Enterprise Architecture study group – Country survey, National
IT and Telecom Agency, Denmark.
Hjort-Madsen, K. (2005). Managing and implementing Enterprise Architectures in Government:
Understanding Institutional Forces and IS Control, Ph.D. Status Report, August 2005.
How SOA works, KL: http://www.kl.dk/_bin/27d196f2-1069-4c4f-9737-cdded2a2b3ee.pdf
214H
IBM's seven key areas for mergers:
http://www-304.ibm.com/jct03004c/industries/publicsector/dk/da/efficientit
215H
IEEE P1471/D5.3: http://standards.ieee.org/db/balloting/ballot.html, 2000
216H
Internet based Questionnaire to the municipal CIO’s: http://www.flemminghald.dk/ea
217H
INTEROP-ESA ´05, Enterprise Architectures – Survey of Practices and Initiatives, Frank Lillehagen &
Dag Karlsen, 2005, Geneva, Switzerland:
http://interop-esa05.unige.ch/INTEROP/Proceedings/Industrial/IND1_Lillehagen.pdf
218H
ISO 15704: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=28777,
2000
219H
ISO/EN I9439 (2003) - Enterprise Integration – Framework for Enterprise Modeling.
IT- og Telestyrelsen: http://www.itst.dk/
20H
Johnson, Bruce. General functionality of SOA: http://objectsharp.com/blogs/bruce/articles/235.aspx
21H
Joppe, Dr. Marion (2005). The Research Process: http://www.ryerson.ca/~mjoppe/ResearchProcess/
2H
KL national webpage (The national association of Municipalities): www.kl.dk (responsible for
http://netborger.dk)
23H
24H
Knippel, Rasmus (2005) Service-Oriented Enterprise Architecture, IT University of Copenhagen
(Master Thesis): http://knippel.org/thesis/SOEA_censored.pdf
25H
Kristensen, Bo & Hald, Flemming (2005). A paper on Enterprise Architecture, Copenhagen Business
School, The Use of Enterprise Architecture in the Merging Danish Municipalities:
http://www.flemminghald.dk/references/EA%20Miniprojekt.pdf
26H
Kuhn, Thomas S.: The revolutions of Science, Copenhagen (1973).
Lakein, Alan. http://www.brainyquote.com/quotes/authors/a/alan_lakein.html
27H
Page 92 of 112
Lankhorst M. & M. (2005). Enterprise Architecture – the issue of integration. Advanced Engineering
Informatics 18 205 – 215.
Lillehagen, Frank and Karlsen, Dag (2005). Enterprise Architectures – Survey of practices and
Initiatives. Whitepaper:
http://interop-esa05.unige.ch/INTEROP/Proceedings/Industrial/IND1_Lillehagen.pdf
28H
Lillehagen, Frank (2003a) and Helge Solheim, “The Foundations of AKM Technology,” Concurrent
Engineering Conference 2003, Madeira, July 2003.
Lillehagen, Frank (2003b) and J. Kostie, S. Tinella, H.G. Solheim, D. Karlsen, “From Enterprise
Modeling to Enterprise Visual Scenes,” Concurrent Engineering Conference 2003.
Martin, James (1995), The Great Transition: Using the Seven Disciplines of Enterprise Engineering to
Align People, Technology, and Strategy (American Management Association 1995), 104.
Martin, James (2004), Enterprise architecture - Definition, internal communication note, 2004.
Maturity of eGovernment in services for citizens and businesses:
http://www.oio.dk/files/whitepaper.pdf
29H
McGovern, James; Ambler, Scott; Stevens, Mike; Linn, James; Sharan, Vikas; Jo, Elias K, A Practical
Guide to Enterprise Architecture, Prentice Hall PTR, December 2003, ISBN: 0131412752.
Miller, Andy (2004). VP of Technical Architecture, Corporate Express, cited in article: “Enterprise
Architects clean house” from http://www.zdnetasia.com/news/hardware/0,39042972,39187785,00.htm
230H
Ministry of Science, Technology and Development national webpage: www.vtu.dk (responsible for
http://danmark.dk)
231H
National EA repository: http://ab.oio.dk/arkitekturbibliotek
23H
National Institute of Standards and Technology – NIST. (1989):
http://www.mel.nist.gov/sc5wg1/arch_fw.htm
23H
News Magazine for the Danish municipalities: http://www.dk.kl.dk/
234H
Nexus, Providing Commercial Solutions to Knowledge Management, http://www.ndyn.com
235H
Office of Management and Budgetting: http://www.whitehouse.gov/omb/#
236H
Open Group (2004). TOGAF Version 8: Enterprise Edition, the Open Group’s official Web version of
TOGAF: http://www.opengroup.org/architecture/togaf
237H
Open Group, Other Architectures and Architectural Frameworks:
http://www.opengroup.org/architecture/togaf7-doc/arch/p4/others/others.htm
238H
Open Group (2000), TOGAF: The Open Group Architecture Framework, Document No. 1910, Version
6, December.
Page 93 of 112
O’Rourke, Carol; Fishman, Neal; and Selkow, Warren: Enterprise Architecture Using the Zachman
framework, Thomsen, 2003, ISBN: 0-619-06446-3.
Popper, Karl: A Pocket Popper, Oxford (1983).
Porter, Michael E: Competitive advantage (1998). ISBN: 978-0684841465
Public Information Online: www.oio.dk
239H
Reference Architecture (2006), a range of reference models and patterns on OIO:
http://ab.oio.dk/gamle-sektioner/referencearkitektur/referencemodeller-og-monstre/
240H
Rico, David F. A Framework for Measuring the ROI of Enterprise Architecture:
http://davidrico.com/rico05a.pdf
241H
Rodd, M. (1994). Enterprise Architecture: Definition, content and utility, The Mitre Organization.
Ross, J. W. (2003). Creating a strategic IT architecture competency: Learning in stages, MIT Sloan
Working Paper No. 4314-03; Center for Information Systems Research Working Paper No. 335.
Sprott, David & Wilkes, Lawrence: Understanding SOA, September 2003, CBDI Journal
Schekkerman, J. (2003). Trends in Enterprise Architecture, IFEAD.
Schekkerman, J. (2004). How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating
or choosing an Enterprise Architecture Framework, Trafford Publishing.
Schekkerman, J. (2005). Enterprise Architecture Tools:
http://www.enterprise-architecture.info/EA_Tools.htm
24H
Schombert, James (2006). Department of Physics, University of Oregon, 2006, js@abyss.uoregon.edu
http://abyss.uoregon.edu/~js/
243H
24H
Schopenhauer, Arthur: http://en.wikipedia.org/wiki/To_be,_or_not_to_be
245H
Spewak, Steven H. (1992). Enterprise Architecture Planning: Developing a Blueprint for Data,
Applications and Technology, John Wiley & Sons Inc., New York.
Strategy for digital strategy for the municipalities:
http://e.gov.dk/uploads/media/Digital_Communication_in_the_Public_Sector_01.pdf
246H
The Butler Group, a Data-monitor company: http://butlergroup.com and
http://computerwire-butlergroup-reports.com/HTML/BGTC0009_ms.htm
247H
248H
The Task Force: http://www.e.gov.dk/
249H
The Ministry of Science, Technology and Development:
http://www.videnskabsministeriet.dk/cgi-bin/frontpage.cgi
250H
Page 94 of 112
The National White Paper: http://www.oio.dk/arkitektur/publikationer/whitepaper
251H
The new Danish municipalities: ftp://ftp2.kms.dk/download/pdf/Gamle_og_Nye_Kommuner.pdf
25H
The new portal of the citizens of Denmark: http://borger.dk
253H
University of Jyväskylä, Information Technology Research Institute (ITRI), Helsinki, Finland, A
practical Approach to EA Planning and Development: The EA Management Grid (2004)
http://www.titu.jyu.fi/julkaisut/muut/Hirvonen_Pulkkinen_2004.pdf
254H
Virtual EA guide: http://ab.oio.dk/arkitekturguide
25H
Vision of the Structure Reform:
http://www.im.dk/imagesupload/dokument/Aftale%20om%20strukturreform%20ny.pdf
256H
Wagner, S. (2005). The Service Oriented Governance – how a successful enterprise architecture is
supported in public organizations, IT University of Copenhagen (Master Thesis).
Wegmann, A. & Preiss, O. (2003). MDA in Enterprise Architecture? The Living System Theory to the
Rescue, Enterprise Distributed Object Computing Conference, 2003. Proceedings, Seventh IEEE
International 16-19 Sept. 2003 Pages: 2 – 13
Weill & Ross, IT Governance (2000), Harvard Business School Press.
Weill, P. & Ross, J. W. (2004). IT Governance – how top performers manage IT decision rights for
superior results, Harvard Business School Press.
Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal
Zachman, J. A. (1997). Concepts of the Framework for Enterprise Architecture, Paper:
www.ozemail.com.au
257H
Page 95 of 112
Interviews
Bang, Mads; Journalist, ComputerWorld
Bouras, Christina; consultant of digital strategy and development at Gentofte municipality, also
employed with Gentofte municipality: http://www.gentofte.dk/
258H
Christiansen, Peter Engelund, IT Architect, IT- og Telestyrelsen
CIO’s from XX and YY municipality
Deth, Steen; IT-architect at Gentofte municipality: http://www.gentofte.dk/
259H
Dohn, Martin; IT architect, The Ministry of Domestic Affairs, http://www.im.dk/im/
260H
Fabrin, Erik; Chairman of KL
Hansen, Peter Gorm; CEO of KL
Harder, Jacob; Consultant, KL, www.kl.dk
261H
Hjort-Madsen, Kristian; Enterprise Architect in the Ministry of Finance, Denmark,
http://www.eagov.com/
26H
Hoej, Preben Rasmussen; CIO for Sollerod municipality: http://www.rudersdal.dk/
263H
Jeberg, Henrik; CIO, The Danish Agency for Governmental Management
Lembol, Hans; CIO of Slagelse municipality: http://www.slagelse.dk/
264H
Karvø, Michael; founder of Center for e-Governance and former chairman of the E-trade Association
Kraglund, Jakob H.; Country Managing Director, Accenture
Svenning, Ellen; chairman of “The Association of Public CIO’s” and CIO of Ringe municipality:
http://www.faaborgmidtfyn.dk/
265H
Sørensen, Rolf, Department Manager, KMD
Vendelbo, Allan; CEO of the Association of City Managers and former city manager for Ballerup
municipality
Windley, Phillip J.; Professor Brigham Young University, Utah, Former State CIO of Utah,
Page 96 of 112
Appendix
Appendix 1: The Study Survey Report
See separate binding
Page 97 of 112
Appendix 2: Zachman Framework
Page 98 of 112
Appendix 3: Bernard’s EA3 Cube
Page 99 of 112
Appendix 4: Framework for Community Mergence by Flemming Hald and Bo Kristensen
Page 100 of 112
Appendix 5: Challenges facing the public sector in the future in Denmark
More elderly
in society
and less in
the working
age
Increased
expectations
from citizens
and
companies
Demand on
opennes and
quick
respons
Limited
resources
The public
sector
Increased
international
competition
Page 101 of 112
Appendix 6: Citizen Survey made by Computerworld and Userneeds,
December 2006
Page 102 of 112
Page 103 of 112
Appendix 7: Map of the “New Denmark” after the structure reformation
Page 104 of 112
Appendix 8: Enterprise Architecture Value Measurement Methods
Framework
Source: http://www.enterprise-architecture.info/Images/Presentaties/NGI%20Congres%202005%20%20Waarde%20Enterprise%20Architectuur.pdf
26H
Page 105 of 112
Appendix 9: The respondents
Geographic location of respondents
Frequency
20
19
15
12
10
5
2
0
0
Zealand
Fyn
Jutland
More
Frequency
Job position of the repondents
35
30
25
20
15
10
5
0
29
2
CIO
1
1
ITITIT-leader
operation architect
leader
0
More
Frequency
Which type of municipality
do you live in?
20
13
17
10
3
0
0
Unchanged
Merging
Split
More
Page 106 of 112
Appendix 10: Internet Questionnaire (http:www.flemminghald.dk/ea)
FIO = Forretningsorienteret IT Opbygning, dvs. samspillet mellem forretningsorienterede krav, ITorganisationen og udvikling af IT-systemer som fokuserer på gensidig tilpasning af forretning og IT, og
dermed en sikring af en forretningsorienteret IT-udvikling. Feedback vedr. spørgeskemaet kan ske her.
267H
Generelle spørgsmål
1. Hvad er din jobfunktion?
-->
2. Hvad hedder din kommune efter 1. Januar 2007?
Vælg her
3. I forbindelse med strukturreformen, hvilken type kommune
tilhører du?
4. En af målene med strukturreformen er at kommunen
fremover skal være borgerens primære indgang til det
offentlige. Alligevel laver KL en fælles offentlig borgerportal i
www.borger.dk. Hvad synes du om det?
Vælg her
Vælg her
borger.dk er overflødig
borger.dk er uundværlig
Ingen mening
4.1 Begrund venligst dit svar
Kommunalt Forretningsorienteret IT Opbygning (herefter FIO)
5. Har din kommune en IT-strategi?
5.1 Hvis ja, i hvor høj grad vurderer du, at jeres IT-strategi
fremover kan bidrage til større anvendelig borgerservice?
6. Har din kommune en EA funktion? (fx. en strategisk ITfunktion)
6.1 Hvis ja, hvordan er den forankret?
Vælg her
Vælg her
Vælg her
I IT-afdelingen
Udskilt i egen enhed
Andet
6.1.1 Hvis egen enhed, understøtter denne direkte det
strategiske/ledelsesmæssige niveau?
Vælg her
6.1.2 Hvilke profiler bemander enheden?
Page 107 of 112
6.1.3 Hvordan træffes beslutninger i denne enhed?
På central plan udenfor enheden
Decentralt i enheden
7. Vedligeholder EA og/eller IT afdelingen en samlet oversigt
over de services (servicekatalog), snitflader, tekniske processer
og datakilder, som indgår i porteføljen?
Vælg her
7.1 Hvis nej, hvem gør så?
8. Arbejder din kommune struktureret med forretningsdrevet
IT?
Vælg her
9. Hvis ja, hvilke(t) ledelsesniveau deltager i en evt.
arbejdsgruppe/projektgruppe vedrørende IT-strategi?
Vælg her
9.1 Hvilke kompetencer besidder disse?
10. Arbejder din kommune med organisatorisk overlappende
grupper? (fx. en medarbejder sidder i to forskellige
projektgrupper)
Vælg her
11. Får din kommune støtte fra eksterne EA/IT-arkitekter?
Vælg her
11.1 Hvis ja, hvornår benyttes disse?
Vælg her
12. Hvordan uddannes IT medarbejderne primært?
Vælg her
13. Er I tilfredse med markedsudbuddet af kurser indenfor IT og
dens anvendelse på strategisk plan?
Vælg her
Motivation, mål og mulige barrierer for tværkommunal FIO
14. Har din kommune opnået konkrete resultater gennem
anvendelse af IT som en del af den kommunale
forretningsstrategi?
Vælg her
15. Hvad kunne være din kommunes primære motivation for at At opnå:
deltage i et tværkommunalt IT-samarbejde vedrørende løsning
Vælg her
af ensartede kommunale opgaver efter 1. januar?
16. Hvad ser du som den største barriere for at opnå dette
tværkommunale IT-samarbejde?
Vælg her
16.1 Hvis andet, hvad?
17. Samarbejder din kommune pt. med andre kommuner om
fælles løsning af fælles opgaver?
Vælg her
17.1 Hvis ja, hvilke opgaver det drejer sig om?
18. Hvordan vurderer du den optimale organisering af fælles
løsning på fælles opgaver i tværkommunalt samarbejde?
Vælg her
18.1 Hvis 'I andet fora', uddyb venligst svaret
Page 108 of 112
Måling af FIO
19. Måler kommunen på sin gennemførelse af IT projekter?
Vælg her
20. Måler kommunen på sin modenhed i relation til brug af IT i
forretningen?
Vælg her
20.1 Hvis ja, hvilken målemetode anvendes da?
FIO Processen
21. Har kommunen offentliggjort retningslinjer, som beskriver
processen for brug af IT i opbygningen af forretningen?
Vælg her
22. Hvad er den største detaljeringsgrad din kommune besidder
af disse offentliggjorte retningslinjer?
Vælg her
23. Har I ladet jer inspirere af andre ved dokumentation af
ovennævnte proces?
Vælg her
23.1 Hvis ja, hvem?
24. Abstraktionsniveau af den offentliggjorte FIO proces?
Vælg her
25. Hvilke aspekter beskriver den offentliggjorte FIO proces?
Vælg her
26. Anvender kommunen specifikke teknikker til at offentliggøre
FIO processen? (fx. website, avisartikler etc.)
Vælg her
27. Beskriver FIO processen også Styring af FIO på strategisk
plan?
Vælg her
28. Beskriver FIO processen vejledning for måling?
Vælg her
29. Hvor mange områder/afdelinger i kommunen anvender IT
som understøttelse til forretningsprocessen?
Vælg her
FIO Framework
30. Har kommunen et offentliggjort framework for
Forretningsorienteret IT Opbygning?
Vælg her
30.1 Hvis ja, hvilket framework/person er I blevet inspireret
af?
Vælg her
31. Hvor detaljeret er den offentliggjorte retningslinje af
frameworket?
Vælg her
32. Abstraktionsniveau af det offentliggjorte FIO/EA framework?
Vælg her
33. Hvilke aspekter omfatter det offentliggjorte FIO/EA
framework?
Vælg her
Anden
34. Hvilke teknikker foreslår FIO/EA frameworket?
35. Foreslår kommunens FIO/EA framework en metamodel? (En
metamodel skal forstås som et værktøj der operationaliserer
arkitektur-arbejdet)
36. Hvor mange områder/afdelinger i kommunen anvender
FIO/EA frameworket?
Vælg her
Vælg her
Vælg her
Page 109 of 112
FIO Værktøj
37. Stiller kommunen krav om brug af bestemte IT værktøjer?
(fx. MS Office, OpenOffice, Open Source værktøjer, ITIL etc.)
Vælg her
37.1 Hvis ja, hvilke?
38. Benyttes ITIL som værktøj i organisationen?
39. I hvilket omfang bliver decentrale IT-anskaffelser
kvalitetssikret eller ligefrem godkendt af EA funktionen?
Vælg her
I meget stort omfang (altid)
I mellem omfang (engang imellem)
I lille omfang (sjældent)
I meget lille omfang (aldrig)
40. Hvem udvikler primært snitflader mellem rammesystemer?
Uvildige konsulenter
Bilateralt mellem leverandørerne
Kommunen udvikler det selv
Anden
41. Er der implementeret en formaliseret bruger identitetsstyring evt. ved hjælp af fælles platform (IAM)?
Ja
Nej
Nej, men der er planer om det!
Ved ikke
FIO Styring
42. Hvordan så du gerne et tværkommunalt FIO/EA
programmet håndhævet?
Gennem lovgivning
Gennem gængs praksis
På anden vis
42.1 På hvilket niveau?
Forvaltningsniveau
Afdelingsniveau
På tværs i organisationen
Alle niveauer
Ved ikke
43. Hvilken karakteristik vil du give af den nuværende
styringsformen af FIO i din kommune?
Vælg her
Nuværende FIO aktiver
44. Hvor stor en procentdel af FIO/EA aspekterne, vurderer du
er beskrevet og ført up-to-date i din kommune?
Forretningsarkitektur?
Vælg her
Informationsarkitektur?
Vælg her
Page 110 of 112
Applikationsarkitektur?
Vælg her
Teknisk Arkitektur?
Vælg her
Anonymitet ønskes!
Nulstil
Send
Tusind tak for at din kommune ville deltage i denne undersøgelse
©2006 KIT@, CBS
Page 111 of 112
Glossary
General terms
EA: Enterprise Architecture
SOA: Service-Oriented Architecture
SOEA: Service-Oriented Enterprise Architecture
EAP: Enterprise Architecture Planning
IS: Information Systems
IT: Information Technology
Danish terms
KIT@: The National Association of Municipal CIO’s
KL: The National Association of Communities
KMD: The largest Danish-owned Information Technology enterprise
NITA: The National IT- and Telecom Agency
STS: Danish National Steering Group for Joint Public Initiatives
MST: Ministry of Science, Technology and Innovation
TADR: The Association of the Danish Regions
ITA: Office of IT Architecture at the NITA
FESD (The Joint Public Electronic Case- and Document Handling)
Page 112 of 112

Enterprise Architecture in Denmark

Transcription

Similar documents

this overview as a

writing module - Carlow University

Title, colophon, preface and symbols

Towards a Danish Spatial Information Infrastructure

info terrasse - Municipalité Terrasse

guatemala local governance/ nexos locales project annual report

PsycNews, No. 3, 2013, 22 July 2013 Department of Psychology

LIEPP Working Paper - Spire

MA Professional Design Practice

report - Action for Mothers and Children