Académique Documents
Professionnel Documents
Culture Documents
Index
1. INTRODUCTION 3
5 ENABLING CHANGE 22
6 CONCLUSION 27
7 EPILOGUE 28
8 REFERENCES 30
9 APPENDIX 31
1. Introduction
It is a goal for the (Danish, ed.) government to improve the public sector service in relation
to its citizens and its commercial business, thus a strategy for digital administration has
been agreed upon. Its goals are to create more coherent and effective IT-systems within the
public sector as a whole. A prerequisite for digital administration is the ability of
government-wide IT-systems to interface directly system-to-system, whether they be federal,
state or county 1 systems. Neither must they impose restrictions on creative thought or
innovation within the public sector. 2
Thus the government formulated its new strategy for the public sector IT-administrative
services in its white-book 3 on digital administration in 2003. The white-book had three
overall suggestions for future IT applications within the public service sector. The first
suggestion was that single or joint public sector services should take responsibility for their
own IT architecture. The second one was for a common IT framework hereby securing
interoperability between systems, and the final suggestion that an effort had to be made to
spread and develop IT architecture competences and public sector initiatives to spread the
use and understanding of Enterprise Architecture.
1
(Stat, Amt & Kommuner)
2
Hand-book: Arkitektur for digital forvaltning p. 5 - See appendix for original Danish text
3
See appendix for details on translations and references for proper name in Danish.
4
The Danish Agency for Governmental Management is henceforth known as ØS which is also the abbreviation in
Danish.
5
Økonomistyrelsens arkitekturprogram p. 5
6
Dynamic Enterprise Architecture p. 15
Large IT systems need to be agile and coherent. A coherent system is a system that shares
information, manages the number of development environments, links applications, and ensures
that interaction between various business processes allow for the organization to present itself in
a uniform manner.
An agile 7 system allows for the business to apply change or react to change in a speedy and tidy
manner. Product development or introduction is increasing constantly and at the same time
consumers expect quicker and more qualified service. All this is possible through the use of
information technology.
The authorities in general do not reuse data and have common functionality, which
leaves every agency to administer their own work processes and IT-systems. This in
turn leaves the employees and the citizens spending time on managing the system
and their data, where they might as well have drawn the same information from
other agency databases. […] From all over in the public sector is the demand for
interoperability and standardised interfaces between systems. The general
consensus is for future IT-investments to reuse and co-think across traditional
boundaries today, to develop the organisation and its competences. 8
7
Dynamic Enterprise Arhcitecture p. 14
8
Hand-book: Arkitektur for digital forvaltning p. 9 – see Danish translation in appendix.
The challenge for the modern organization is finding the correct balance between coherence
and agility.
The solution must be based upon a hierarchical architectural layer and built from
modules 9 .
These modules that the architecture consist of means that the entire architecture is easier to
understand and easier to work with. Especially when it comes to changing certain parts. This
leaves functionality to be developed separately in many different teams, and when they are
re-combined, they still carry the intended functionality. These singular modules must be kept
up-to-date and adhere to new demands. New challenges to the architecture could be new
legislation that affects calculation methods, but if the architecture remains agile then modules
are easily changed and re-adapted. 10
All too often, an architect’s efforts result in piles of paper that are of no practical use to a
project team, and instead of being used, immediately disappear in some drawer.[…]
Business owners and managers also perceive architects as meddlesome […] 11
9
Arkiteturvision og –principper p. 11
10
Arkitekturvision og –principper p. 14
11
Dynamic Architecture p. 28
To achieve an architecture that is both coherent and agile, the Dynamic Enterprise
Architecture methodology uses 10 principles to guide the optimum use of architecture.
DYA uses 10 principles for precepts and presumptions when working with Dynamic
Architecture, ØS also developed their own 10 architectural principles to guide their non-
technical requirements 12 . These are not directly comparable but in many cases they are related.
They are compared in the following to off-set each other. Not all 10 principles are included in
sections 3.1.1 to 3.1.8 as they were not deemed relevant.
12
Ikke-funktionelle krav, translated from danish
15
Økonomistyrelsens kravkatalog p. 3
16
Arkitekturvision, Økonomistyrelsens arkitekturvision og –principper p. 3
17
Dynamic Enterprise Architecture p. 54
18
Bernard, Scott A. – Introduction to EA
19
Bernard terminology – p. 175
20
Bernard p. 108
21
Styringsmodel p. 1
22
Styringsmodel p. 2, see Danish text in appendix.
23
Hand-book: Arkitektur for digital forvaltning
24
Styringsmodel p. 1
25
Kortlægning af ØS forretningsarkitektur
26
Forretningsarkitektur p. 11
27
Dynamic Enterprise Architecture p. 64
Continous
Development process
IT solution: process IT solution:
High ad hoc problem improvement High ad hoc problem
Solving content Solving content
IT solutions:
High anticipatory
content
The anticipative strategy is the default strategy, that is to say it reflects any architecture that has
been agreed upon. The anticipative strategy is aimed at predicting future events and needs of the
organisation. Thus it produces highly anticipatory contenst to handle all future scenarios, break-
downs, threats, possibilities and weaknesses. Within the setting of this paper it is rather irrelevant
since any architecture solution out there, e.g. Carbone or Bernard’s, could provide this strategy
for architecture.
The defensive / offensive strategies are the interesting ones because they both pertain to
problems outside the organisation and what they solve in matters of architecture is primarily
based upon speed. Because speed is of the essence, architecture will suffer, but because
organisations apply these solutions to address challenges to the organisation’s
competitiveness, it is necessary to control this ad hoc problem solving and make it fit within
the organisation’s architecture.
TRADITIONAL TIME-BOXING
time
functionality
money
quality
money quality
Variable
Fixed Variable
Fixed
functionality
time
To increase the speed with which applications are constructed, several new IT development
methods have been created such as DSDM(Dynamic Systems Development Method 28 ) and
XP (eXtreme Programming 29 ). Both of them reflect the above timeframe perspective and
their assumption is based upon the fact that a usable and significant part of the system
(around 80%) can be constructed in 20% of the time needed to build the complete system.
Time-boxing is also such a strategy with set beginning and completion dates. In traditional
development methods “time” and “money” were variables that could be changed to achieve
success, and “functionality” and “quality” were fixed variables that ought not to change. With
time-boxing this is turned around so that money, quality, and functionality all are variables that
can be changed and give way to “time” as a fixed factor 30 , thus changing the goal from a
product-driven approach to a time-driven one. Should it be evident that the deadline set for a
28
http://www.dsdm.com/en/about/history_more.asp
29
http://www.extremeprogramming.org/
30
Dynamic Enterprise Architecture p. 154
Because there is no set path for relegating the quality or interoperability of architecture
developed outside of architecture, the product-life cycle is set to be very short and while a
product developed from an offensive or defensive strategy is being taken into use, a strategy
for harmonising the product with the overall strategy should be started. In this case the out-
of-architecture product is being planned back within the anticipative strategy.
If parties fail to state and start an anticipative strategy at the beginning of the defensive /
offensive strategy, chances are that it will never happen. 32
If not handled right away, it is very easy for management to say “why waste more resources
on something that works?”, which is a valid point except that the final product is not final. It
does not interoperate well with the rest of the architecture and does not allow for updates or
further implementation or streamlining.
As stated at the beginning of the paper architecture must be both coherent and agile, if not, it
is not competitive or efficient. In regards to the three above mentioned strategic initiatives
coherence is found within the anticipative strategy, where agility or the ad hoc solution is
found quickly by adapting an agile strategy like the offensive or defensive.
ØS has clearly set the stage for an anticipative strategy. They work in an environment where
ad hoc, although ingenious, solutions will not work because data in one place of the
31
Dynamic Enterprise Architecture p. 155
32
Dynamic Enterprise Architecture p. 156
5 Enabling Change
All organisations or businesses are different from each other. This difference is also visible in
how willing an organisation is to change its current architecture. To enable change in an
organisation it is relevant to understand its readiness in regards to a new architecture.
Model 1.0 33 can be helpful in describing how ready ØS are for their new architecture.
Architectural awareness
High
vision and policy on IT and architecture. Isolation Enabling
ØS themselves did not define the strategic
initiative, this was defined for them in the
white-book and the hand-book by MVTU.
Low
Losing Barrier
This, however, does not mean that it is not
an integral part of the overall policy of the
organisation, it just means that the decision
Low High
to go ahead and start the initiative has not Integration in the organisation
been up to them. Model 1.0
Integration in the organisation pertains to how serious the organisation is about its change. This
is typically reflected in the amount of money and people dedicated to working with the new
architecture and their available resources.
Any organisation going for change should try and end up in the enabling quadrant. If an
organisation finds itself in the losing quadrant, IT is not perceived as being strategically
important; there is no alignment between IT and business, there is no IT vision nor are there
resources allocated to IT, which is also why IT is neither effective nor efficient. In the barrier
quadrant it gets slightly better. The integration of IT within the organisation is higher but it lacks
purpose. IT is still not perceived to be strategically important and thus alignment between IT and
business does not take place. The IT vision, strategy, and policy exist but are lacking in purpose.
The resources spent on IT are sufficient, but remain unfocused, and they are thus not effective.
Due to the lack of IT and business alignment, the business seeks solutions to problems elsewhere
outside of the organisation, and not with the internal IT department.
33
Dynamic Architecture p. 45
ØS and in this case to some extent the government, has planned to realise more effective and
efficient systems for agency-to-agency communication, but also to realise more services for
citizens, and to cut down on expenses. There is a firm strategic vision from above, all explained
in both the visionary paper of the white-book, with a practical explanation in the hand-book.
They are all testament to the government’s dedication to business service IT alignment. The
government has realised that architecture needs to be institutionalised so that it becomes an
integral part of the way the government functions. ØS is located within the enabling quadrant
because IT is perceived to be of strategic import not only to themselves but also by government
in general. Business and IT alignment often take place, because the government chooses to use a
business driven model.
34
Dynamic Enterprise Arhictecture p. 46
Teknologi
Standardisering Grunddata Data
Fælles grund- tilgængelige
Datacenter som dataobjekter
Data Warehouse databaser
Standardiseret Ensartede
Applikations-siloer Moduler
teknologi data
Arkitekturmodenhed
©2003 MIT Sloan CISR, Ross. Used with permission. All rights reserved.
The above model like the Enabling model presented previously also depicts how ready for
change or where on a scale on readiness a company is. The Strategic Choice phase on the far
right is where the white-book wants government services to end up. They are characterised
by being accessible in modules with a high agility that allows them to be combined in new
strategic alliances, in the case of ØS this would translate to a sort of Service Oriented
Architecture for the citizen that provides new services through modules made available from
many different agencies. Where ØS is today is hard to say, but a fair guess would be phase 2,
but from the reports and papers and the strategic goal the government has set for its agencies,
ØS is striving to fulfil the fourth phase, strategic choice.
35
Hand-Book p. 19
The S.M.A.R.T. as a rule-of-thumb is a good tool in case something needs testing for validity
in relation to project principles or strategic vision. But in the case of ØS it is hard to apply
and even justify its use because it falls short of pointing out real critique. That most of the
strategic decisions defined by ØS fall outside of the scope of the S.M.A.R.T. method is a
36
Dynamic Enterprise Architecture p. 76
37
Arktitekturvision og –principper p. 5
38
Arkitekturvision og –principper p. 3
6 Conclusion
ØS do not apply an “Enterprise on-the-fly architecture”, they document the way “traditional”
EA is done, like explained by e.g. Bernard. Meaning ØS spends a lot of their time in the
documenting and documentation phase, they do not apply methods of agile development
with the use of e.g. eXtreme Programming. They do however have a business-driven
approach to Enterprise Architecture. By that is meant that the goal of the entire process is to
align public sector services for citizens with a system or architecture that support this focus.
ØS’s EA project is not meant to make working in the government or public agencies easier
for the employees, but to make all services interoperable so that citizens of Denmark may
have access to all public services through the same platform. This in turn also achieves a
more flexible system that allows for a reduction in work-load for employees, and hence also
economic benefits for the state.
Because ØS do not apply all or large parts of Dynamic Enterprise Architecture, the parts that
are less relevant when explaining Dynamic Enterprise Architecture have been left out. The
three “action” strategies (offensive, defensive and anticipatory) are some of the more
important points in Dynamic Enterprise Architecture and what also off-sets this theoretical
approach from others’. But ØS is in no hurry to develop an early test version and then
develop from there, they have a need for a precise understanding and having all parties
involved in the process. The reason for this is because there is no-one expert on how
government systems functions today state-wide or how work-processes interoperate. These
loose couplings must be identified and built into the system too. What the employees solve
by picking up the phone unofficially in a case must be supported in the system so this extra
work becomes redundant.
7 Epilogue
This project has had a difficult birth and a rough landing. It started later than expected due to
mal-communication with a potential company, but I ended up writing this case instead.(A
very interesting one I might add.) And it was tough to finish this paper because I got sick for
a period of several days. All in all this lead to a few discrepancies in the working process that
led me to strike a few things in the work process. This needed saying before a personal
recommendation or critique can be put forth.
Due to the above circumstances I did not have the time to conduct interviews and thus some
of the points in my critique below, could probably easily be answered by meetings, emails or
even over the phone.
ØS seem to have been straight A-students of Enterprise Architecture! Their material is to the
point, concise, descriptive, structured, organised and divided into relevant papers according
to EA subject.
ØS and the government both have made it their strategic plan to educate people within the
field of EA and get competent and responsive EA workers all over the public sector. This
seems evident from both all the working papers that all explain what the process is about,
where it leads to etc. And further reading and education could then be the hand-book. They
are successful in leaving materials to educate people.
What troubles me the most is that at no point can I feel that the actual people that work in the
organisations have been involved in the process. Yes! Sure they have been asked to cover a
range of applied terms in the work-processes and probably been involved in identifying
actors across the organisation and their working relationship.
ØS’s in-depth description consists of pretty much these hierarchically layered components:
Strategic Process, work-process, terminology, terminology in work-processes, supporting IT
system, actors and geographical location. 39 And this is definitely a proper way of
documenting if you ask me, but through-out all the papers supplied by ØS there is no trace of
the involvement of actual workers from the sub-departments or agency-wide. A typical
39
Kortlægning af ØS forretningsarkitektur p. 78
But non-the-less it would be interesting to see some user-based case scenarios, if for nothing
else than just to prove that the documentation effort is working. To this end Dynamic
Enterprise Architecture could warrant a closer inspection.
40
The theory of gestalt is that an entity is more than the sum of its parts; the Gestalt Effect.
8 References
• Dynamic Enterprise Architecture – How to Make It Work. Wagter, R., van den Berg,
M., Luijpers, J. & van Steenbergen, M. – John Wiley & Sons Inc., Hoboken, New
Jersey.
• Arkitektur for digital forvaltning – Håndbog om begreber, rammer og processer.
Ministeriet for Videnskab, Teknologi og Udvikling (MVTU). Videnskabsministeriet
og IT- og Telestyrelsen, oktober 2004.
• Vejledning til Økonomistyrelsens referencearkitektur, 10-05-2006 version 3.0
• Økonomistyrelsens arkitekturvision og –principper, 09-09-2005 version 1.1, IT-
enheden/klk
• Økonomistyrelsens kravkatalog, 10-05-2006 version 2.0
• Styringsmodel for arkitekturarbejde i Økonomistyrelsen, 27-09-2005 ITE/asa/klk
• Kortlægning af Økonomistyrelsens forretningsarkitektur, 10-05-2006 version 2.0,
oese21
• Økonomistyrelsens arkitekturprogram, Oracle den 28. april 2006(PowerPoint), Chef
arkitekt Kim Lindskov Knudsen
• An Introduction to Enterprise Architecture: Second Edition. Bernard, S., AuthorHouse
• IT Architecture Toolkit. Carbone, J., A.. – Prentice Hall PTR, Upper Saddle River
• http://www.dsdm.com/
• http://www.extremeprogramming.org/
• http://wikipedia.org/
9 Appendix
1. Hos offentlige myndigheder er der generelt kun lidt genbrug af data og funktioner, så
hver forvaltning har arbejdsgange og it-systemer, hvor medarbejdere og borgere
bruger tid på at administrere data, som lige så godt kunne læses direkte ind i andre
forvaltningers systemer. […] Mange steder i den offentlige sektor efterspørges
samarbejde om interoperabilitet og standardiserede snitflader mellem systemer. Der er
et udbredt ønske om at kommende it-investeringer skal fremme genbrug og
samtænkning på tværs af nuværende skel, for at kunne udvikle organisation og
kompetencer.
2. White-book is a direct translation of the Danish word Hvidbog to distinguish between
two almost identical papers produced by MVTU. The white-book is the visionary vue
on digital implementation in the public sector.
3. Hand-book is a direct translation of the Danish word Håndbog to distinguish between
two almost identical papers produced by MVTU. Hand-book is the practical
implementation of the visions from the White-book.
4. Regeringen har som mål at forberede det offentlige Danmarks service over for
borgere og erhvervsliv, og har derfor lagt en strategi for digital forvaltning, der skal
skabe en mere sammenhængende og effektiv it-anvendelse i den offentlige sektor. En
af forudsætningerne for digital forvaltning er, at it-systemerne kan fungere sammen på
tværs af forvaltningsgrænser og på tværs af stat/amt/kommune, samt at it-systemerne
ikke lægger hindringer for nytænkning og innovation i den offentlige sektor.
5. Styringsmodellen har ikke til opgave at sikre, at arkitekturarbejdet bliver gennemført
som et big-bang. Styringsmodellen er derfor skabt til at virke på et hensigtsmæssigt
niveau både i forhold til den administrative byrde, der følger med de krav den sætter,
og i forhold til den eksisterende projekt-, kontrakt- og økonomistyring.