Dynamic Enterprise Architecture and Practical EA

- T8 - Enterprise Architecture Spring 2006
Enterprise Architecture 4 week project
Dynamic Enterprise Architecture and practical EA

- How government IT-strategy in the public sector
is realised through EA
IT-University of Copenhagen spring 2006

Simon Kaastrup-Olsen
IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 1

Index
1. INTRODUCTION 3
1.1 AREA OF CONCERN 3

1.2 MOTIVATION FOR EA INITIATIVE 4
2 AGILITY AND COHERENCE 5
2.1 DYNAMIC ARCHITECTURE 5

2.2 POTENTIAL OF INFORMATION TECHNOLOGY 5
2.2.1 TENSION AND CHALLENGE 6
2.2.2 WANTED: AGILE ARCHITECTURE 7
2.2.3 NEEDED: COHERENT ARCHITECTURE 8
2.2.4 DYNAMIC ARCHITECTURE: ARCHITECTURE AIMED AT AGILITY 9
3 “TEN” PRINCIPLES OF DYA 10
3.1.1 ARCHITECTURE IS STRATEGIC IF IT IS STRATEGIC 11

3.1.2 ARCHITECTURE MUST FACILITATE SPEED OF CHANGE 11
3.1.3 COMMUNICATION BETWEEN BUSINESS AND IT MANAGEMENT IS CRUCIAL 11
3.1.4 BUSINESS OBJECTIVES GOVERN THE DEVELOPMENT OF ARCHITECTURE 12
3.1.5 ARCHITECTURE MUST BE DEVELOPED “JUST ENOUGH, JUST IN TIME” 13
3.1.6 WORKING UNDER ARCHITECTURE IS SUPPORTED BY A THEORETICAL AND WORKING MODEL 14
3.1.7 TRANSPARENT RELATIONSHIPS MUST BE DEFINED 14
3.1.8 SEVERAL DEVELOPMENT STRATEGIES ARE DISTINGUISHED 15
4 WORKING WITH(OUT) ARCHITECTURE 17
5 ENABLING CHANGE 22
5.1.1 STRATEGIC DIALOGUE 25
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.1 Area of Concern

Økonomistyrelsen (ØS), the Danish Agency for Governmental Management, is currently
pursuing an Enterprise Architecture strategy for implementing change within their organisation,
this endeavour is currently underway.
The scope of this paper is concerned with describing Dynamic Enterprise Architecture
through the practical implementation of Enterprise Architecture at the above mentioned
government agency.
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.

The paper has a three pronged approach to the subject of Dynamic Enterprise Architecture:
an organisation’s architectural agility and coherence, how prepared an organisation is for
change, and finally how to develop architecture with(out) architecture. Not all of these are
equally relevant, but all will be subject to scrutiny and exemplification in relation to the
chosen case.
Contrary to the common apprehension of government initiatives I am of the belief that ØS is
very much prepared for change and that the reason for this is due to the government’s
strategic belief in interoperating services. I do not expect ØS to apply a Dynamic Enterprise
Architecture to a high degree, but expect to find some commonalities between the two.
1.2 Motivation for EA initiative

In 2005 Økonomistyrelsen (ØS) 4 , the Danish Agency for Governmental Management, chose to
change their current IT structure and use Enterprise Architecture as their primary driver in their
realisation of the above mentioned strategic initiative. The reasons for starting their architectural
program were:
• The Ministry of Science, Technology and Development has in its white-book placed a
significant emphasis on architecture.
• IT costs are cutting into the agency’s budget and IT is also demanding more in other
ways.
• A need for control of own architecture in order to support a coordinated effort and
development in all other areas dependent upon this architecture.
• A wish to develop architectural competences and become more adept in making
demand specifications. 5
4
The Danish Agency for Governmental Management is henceforth known as ØS which is also the abbreviation in
Danish.
5
Økonomistyrelsens arkitekturprogram p. 5

2 Agility and Coherence
2.1 Dynamic Architecture

Architecture, in the context of this paper and Dynamic Enterprise Architecture, is the consistent
reuse of data and models that guide the design and implementation of processes, organisational
structures, information flows, and the technical infrastructure within an organisation. In other
words architecture can be considered a set of agreements that ensure that individual
developments interface correctly with each other and with overall company interests. Dynamic
Architecture is explicitly aimed at achieving business goals quickly in a constantly changing
environment;that is: which architecture is to be designed at what moment and for what purpose,
who is involved and why..
2.2 Potential of Information Technology

In the 1970s and 1980s, business processes were redesigned once every seven years 6 on
average. At that rate the IT departments in most companies could still keep up with the pace
of change and the information systems that needed changing adapted within acceptable
timeframes. In the 1990s the pace increased, and did so again from the year 2000 and
onwards; the rate has been ever increasing, but the pace of implementation remains the same,
and today it is inconsistent with the need for change and the speed with which the new
systems are being implemented. The reorganization within companies reflects both a fast
paced competitive business and the speed of technological breakthrough, and its recognition.
If the organization decides to fast-track the implementation of a new system, they end up
with a semi-functioning system or a system addressing the wrong needs.
Information technology has the potential to remove most trivial tasks at work and at home by
standardizing and trivializing the work process. Information technology has the potential to
remove redundant work, information or procedures and streamline operation. Information
technology has the potential to reduce the complexity of systems and work processes, again
by standardizing or even ignoring irrelevant information, leaving the users with needed and
relevant information for warranted decisions.
6
Dynamic Enterprise Architecture p. 15

In some cases this is actually the case, in other cases information technology or more
specifically large corporate or public sector systems end up being appreciated as much as a
rainy day in July. A good example of this, from the public sector in Denmark; is the case of
Amanda.
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
2.2.1 Tension and challenge

Information technology today permeates every single part of the modern organization and is
the single factor for competitive advantage, and is no longer just a tool. A fact most
competitive businesses appreciate and take to heart by applying and implementing newer
systems continuously. The challenge is for developers to facilitate both an agile process and a
7
Dynamic Enterprise Arhcitecture p. 14
8
Hand-book: Arkitektur for digital forvaltning p. 9 – see Danish translation in appendix.

coherent system, and speed is of the essence to gain a competitive advantage. The challenge
is to address the needs of all involved stakeholders.
In the past the relationship between businesses, suppliers, employees, processes, and information
systems were integrated to a certain extent. However, customers and suppliers played no active
role in the company’s business processes. This relationship has evolved within the last 20 years
and suppliers are today no longer a separate entity; but more and more a part of the individual
company’s value chain. On the one hand it has led to a more effective and efficient operation, on
the other hand it has increased the complexity of business processes. The complexity of this new
business model combined with a Just-in Time principle, to lower the price per unit, has greatly
increased the amount of time needed to categorize, document, and implement new information
systems, e.g. ERP, CRM etc. This increase in “production time” for a coherent system is not
something management takes lightly. They need a business model that addresses today’s needs
yesterday, so the architect responsible for this process is hard pressed for results while at the
same time he or she is faced with getting the appropriate information for the system.
The challenge for the modern organization is finding the correct balance between coherence
and agility.
2.2.2 Wanted: Agile Architecture

There are two aspects to dynamic architecture when it comes to agility. The first is aimed at
content, in this case architecture is a product. A product that changes with a changing
environment allowing the architecture to quickly support changes in the business processes.
The second aspect is how the business handles architecture within the organisation. What
processes make up the organisation and how to identify them? This approach is aimed at
breaking down IT support into separate blocks that can be developed, maintained and
changed independently of each other. This enables the organisation to quickly change
underperforming parts of the organisation.
For an architecture to change according to its environment it needs to have an agile
architecture with highly anticipative contents, more on this in section 4.0, and to quickly
develop or redesign the architecture of the company it is necessary to change the building-

blocks. In Bernard terminology this translates into EA components that can be separately
redesigned or removed completely.
This need for agility is also reflected in the architectural principles that ØS set for their
project, they state:
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
2.2.3 Needed: Coherent Architecture

Whenever conventional EA is initiated, it usually implies a huge amount of work
documenting the entire organisation and creating a lot of papers identifying work-processes,
people, business needs, etc. Another hindrance to a quickly implemented architecture is the
fact that architects are not always valued for insight into the inner workings of an
organisation.
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

Architects are accused of being a hindrance to a business’ need for a competitive opportunity
when they explain the impossibility of a sought-after business opportunity.
Everyone agrees that a coherent architecture is needed for the business to function properly,
but all see the cumbersome work in achieving this coherence. And all too often when a new
architecture is implemented, it does not reflect the real-life organisation that it was intended
to serve.
For an architecture to be successful and thus be coherent architects need to document large
parts of the organisation. If not, the strategy that will define the future architecture will not be
highly anticipative and therefore not successful either.. See section 4.0 for more on the
anticipative strategy.
ØS has a very classical approach to doing Enterprise Architecture meaning that they spend a
lot of time documenting every part of the organisation from positions, geographical
locations, work titles, work processes, terms used in various departments or in specific work
processes. But ØS have two actors to take into account. The EA process is not one only
ordered by top executives, but by the government itself and one of the formulated purposes
of doing EA is also to spread the knowledge of EA. This is done by both documenting the
organisation and explaining what all these terms are, but part of the job is also educating
government or agency employees in what EA is and what it can do for the organisation and
its customers. Coherence for the agency architects is to have employees feel part of, or at
least accept, the changes the agency is undergoing. Which is good because the government
also wants a business-oriented solution, meaning that the new systems developed are targeted
at the users of the agency’s services and thus the functionality of the new government-wide
system is oriented not only towards the employees, but also towards the customers of the
agency. And the lack of a coherent understanding between system and employees could
prove disastrous to both employees and customers alike.
2.2.4 Dynamic Architecture: Architecture Aimed at Agility

The principle behind Dynamic Architecture is not another theory or method of how to design
architecture. Professionals like Zachmann, Carbone, and Bernard already did this. Dynamic
Architecture is about which architecture to design, at what moment and for what purpose,

who is involved in the design process, and who is going to use the architecture and to what
end.
In this context the real issue to address is how this new architecture is to be employed within
the organisation. The main stakeholder must realise that it is a multi-disciplinary venture by
both business and IT managers. They must together realise how the architecture is done.
Choosing to develop an architecture is achieved through a concrete business objective. This
focus defines the priority of these architectural activities, so that the most important and
relevant activities come first and some wait till later. This way a functioning architecture is
realised quickly with the most essential parts in place.
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.
3 “Ten” principles of DYA

The Dynamic Architecture Model (DYA) is a model that helps its architects sort through
needed strategic decisions and its conception is of a practical nature, not theoretical. Whether
architects decide to use the entire model or only parts is of no importance. The model is
meant to adapt to the project, not the other way round.
Like many other frameworks or toolsets in the EA tradition DYA uses principles or standards
for guiding the project details. Principles are effective because they are easy to remember and
should architects be in doubt they can use the principles as a benchmark and then decide
whether to use some or not.
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

3.1.1 Architecture is strategic if IT is strategic
For an optimal application of IT within the enterprise, the use of IT must be understood, e.g.
where in the organisation and who in the organisation need IT and for what purpose? When
attracting customers and retaining them succeeds, it is because the underlying IT is
purposefully applied.
ØS decided to have as a principle that all solutions must be based upon a common agreement
on standard. 13 For the users of government public services this meant that using the same
system or information across all public IT-services is one way of attracting and retaining
users. One singular product, even though it is good, has a hard time competing with 10 good
products all interoperable.
3.1.2 Architecture must facilitate speed of change

Today organisations must reinvent their services constantly. The strategic decision making at
the top is easy to agree upon, but aligning IT capabilities is another story. Architecture should
be an enabling factor in developing new systems to match new strategies. 14 ØS decided that
their principle of facilitating change is the storage of data in one place and then reusing it
across the agency.
This would allow architects to find information in one place only and change it there for
agency-wide implementation allowing a faster adaptation.
3.1.3 Communication between business and IT management is crucial

To realise the full IT potential it is necessary for both business leaders and IT management to
agree upon a common strategy. Sound communication between business decision makers and
IT managers allow the business to align strategy with the tools that make them create
strategy.
For ØS they created a paper on non-functional requirements. This was to ensure that matters
of business strategy corresponded with IT solutions without them being a discussion of
technical matters, an area business leaders are not all to comfortable with. ØS also stated in
13
Økonomistyrelsens kravkatalog p. 4
14

this paper that the single most important criteria of the paper is its acceptance and
compliance internally within ØS, by both senior, middle and IT management. 15
3.1.4 Business objectives govern the development of architecture

Within all businesses the restructuring of IT architecture should be done for the sake of
realising new opportunities and strategies, not for the sake of realising IT architecture.
The government’s single minded decision to implement new systems that all interoperate
across federal, state and county systems is based upon the concept that interoperable systems
equal good systems. So the government´s decision to implement interoperability nation-wide
stems from the wish to make IT implementation and restructuring more agile and coherent.
Thus the decision for ØS to go ahead and initiate an IT restructuring originates from this
government strategy. One way of seeing this change is that the ØS has no true need for this
restructuring right now and that the DYA principle is correct in its assumption that in this
case the architecture is for architecture’s sake, not for the realisation of concrete specific
agency needs. In this light ØS’s decision to implement EA comes off badly.
Another way of understanding this DYA principle is differentiating between government
decions and business decisions. When it comes to businesses and mid-sized organisations
and it comes to state operated agencies, they differ in more than just size. The government
governs the country, so to speak. They have to offer services across the public sector and as
such they do not make any money from this service. In the case of the government decision
the term “better safe than sorry” comes into play.
The reason for the change is to promote public service and ?wide interoperable and coherent
systems, and setting the stage for individual agencies to take responsibility for IT systems.
In a business-setting their strategic decision would have been formulated as: “We need to
optimise our communication company-wide to facilitate a higher throughput of products and
increase service, while decreasing cost on IT implementation.”
Not that this is not the goal of the government also, but this formulation is too specific a strategy
for the government to apply to very different agencies. Thus, a general declaration of intent is
realised with a loosely defined objective that in turn allows each agency to develop a specific
15
Økonomistyrelsens kravkatalog p. 3

strategy to fit within the scope of the government-defined one. This strategy is addressed in the
ØS visionary architecture 16 .
3.1.5 Architecture must be developed “just enough, just in time”

The 6th principle of the DYA (above is 1-4) reflects the true nature of Dynamic Enterprise
Architecture. “Just enough, just-in-time” development means that the various components of
architecture will only be developed when it is clear how and for what purpose they will be
used. 17 Any EA process catalogues, simplifies and objectifies reality/ an organisation. If not, no
remodelling with e.g. EA would be accomplished. Once this documentation effort is complete -
e.g. in Bernard’s theory all documentation is stored in a Repository 18 - it is time to decide what
parts are crucial for the process, and what parts are not, a sort of critical path or linear necessity.
Dynamic Enterprise Architecture is the boil-down to components that are mission critical and
leaving the rest for later. In this way results happen fast, thus feedback and adjustment is also
quickly achieved.
ØS have created several working papers in the effort to control, document, and realise EA
throughout their organisation, one such paper the “Styringsmodel” - which is roughly equivalent
to Bernard’s chapter about the EA Management plan 19 - is concerned with how to specify
Common threads, Cross-cutting components and Lines of Businesses 20 . This guide to
implementation of EA describes what projects to start and what requirements are set in order to
realise the architectural principles and vision agreed upon between management stakeholders. 21
This EA management plan differs slightly from the DYA principle in respect to pace.
The EA management plan is not meant to implement architecture by way of Big-Bang

application, but to assure coherence between administrative efforts […] and existing […]
agency efforts. 22
16
Arkitekturvision, Økonomistyrelsens arkitekturvision og –principper p. 3
17
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.

ØS does not want to go all the way and potentially risk disruption of daily operations, but
opts for a more tentative approach. The DYA principle states that the more need for a specific
business objective, the more architects involved, the less something is of importance, the less
architects. Without concrete knowledge of available architects for this EA endeavour it seems
prudent to be cautious when affecting change.
3.1.6 Working under architecture is supported by a theoretical and working

model
As stated above, any model or theory is a simplification of reality/an organisation. Thus a
business needs to preclude any sort of step-by-step or recipe for implementing change. There
is no cook-book or one correct way to apply change. The DYA principle is that any change
effort must draw from a melting-pot of applicable theories and models.
One of the founding principles of the ØS architectural vision and their principles is for ØS to
develop their own architecture. The basic skeleton for their approach is the white-book produced
by MVTU. This is only a visionary approach, which leaves ØS to pick and choose as they see fit.
One place to find inspiration is the Hand-book 23 which gives practical application to the
visionary approach defined in the White-book also by MVTU. ØS chose a business-driven model
or architecture, because the architectural principles and vision are founded on business-strategy
to help address the relationship between IT and business. Thus they try to realise a business-
driven architecture. 24
3.1.7 Transparent relationships must be defined

For any change to happen an organisation must understand its current architecture and define
what relationships connect processes, objects, and shared information. A clear insight into
these relationships helps determine which domains of the architecture need further
elaboration.
23
Hand-book: Arkitektur for digital forvaltning
24
Styringsmodel p. 1

ØS decided that their documentation effort consisted of defining common denominators like
terms, actors, location and processes. 25 On the below picture 26 is a description of who are
involved with Running SLS which is the bi-monthly payout of employee cheques. On the left
hand side you will find the process and on the right hand side the people involved in this
particular process. In the middle is a brief description but also which of the actors on the right are
responsible.
Should architects decide to change the way that ØS runs its salaries, they need look no
further for an architectural description of what processes take place, who are involved and
how responsibility is divided. For instance ØS could choose to outsource their SLS system to
another company than CSC. By having this detailed relationship it offers a competitor
qualified insight and gives the possibility to set a much more precise price., which ØS could
reject or accept in relation to their agreement with CSC.
3.1.8 Several development strategies are distinguished

Should a business have a specific need and pressure to develop its strategy quickly, it is possible
to co-develop several parts of the architecture at the same time. The key to success is to
implement three strategies: (1) the anticipatory strategy, (2) the defensive, and (3) the offensive
25
Kortlægning af ØS forretningsarkitektur
26
Forretningsarkitektur p. 11

27
strategy. See the following section for more details. ØS is still gathering data on its
organisation, but it seems unlikely that ØS would choose such strategies because they are rather
strategies that are meant for an open market place, meaning that if you have a product you want
to sell to others or if you need to position the organisation in relation to the market, ØS needs
neither strategy because its only goal is adhering to government decrees and serving its users:
The People. Not that some government services are not outsourced but for what ØS does, no
company could usurp their position. Alas, the three above mentioned strategies are a defining
part of Dynamic Enterprise Architecture and thus warrants a brief introduction.
27

4 Working with(out) architecture

Whenever an organisation works with architecture, this might be compulsory or not, at one
point architects or stakeholders will step outside of the agreed-upon architecture. It is
inevitable. The reasons are manifold and could be anything from a specific systemic solution
to a compatibility problem. The problem arises when the systemic solution does not meet the
architectural demand for interoperability. Another such reason might be that one solution is
either simpler to develop or cheaper. Working within the boundaries set by the architecture is
not always easy or the fastest way.
To handle this autonomous gene in many designers and people working outside of
architecture, the Dynamic Enterprise Architecture concept consciously accepts deviations
from architecture – development without architecture – within the architecture. Thus,
development without architecture is a controlled event and within the set boundaries of the
overall architecture. To do this the Dynamic Enterprise Architecture works with 3 overall
development strategies within the development without architecture setting.

Defensive Anticipative Offensive
Organisation is Organisation Organisation

taken by surprise chooses structural achieves one-off
solution competitive
advantage
Short-term solution Business- IT Short-term solution

organisation organisation
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
To reach business objective quickly
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.

For the defensive / offensive strategy it is of crucial importance to set dates for a project start and
end. Irrespective of what happens during the course of the project, the deadline remains
unchanged. If the deadline is endangered in any way, it will not be postponed, but certain aspects
of the functionality will be sacrificed. The costs incurred by this strategy can be great, but
because speed is of the essence the quality of the solution is to a large extent also defined by
being completed within this time-frame.
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

certain product is still going to pushed ahead, then the offensive or defensive strategy can apply
the MoSCoW princple 31 .
• Must haves – are the parts of the system that are absolutely critical for basic
functionality
• Should haves – If time had permitted it these requirements are almost as important
as Must haves.
• Could haves – the parts that are easier to omit from a partial delivery
• Want to haves – of no essential requirement, and can wait for a second phase
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
32

governmental apparatus must be available in other places. A motive for an organisation to
employ an offensive or defensive strategy could be the lack of funds. ØS might not have all
the funds in the world, but a fair guess, although uneducated, would be that the Danish
government are planning ahead and thus have set aside sufficient funds to complete a proper
documentation phase and also left enough for a proper identification and analysis to further a
highly anticipative system that will work agency-wide.

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 (on the left hand

side) relates to if ØS possesses a realistic
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

Going opposite the barrier quadrant in the model above and away from Integration in the
organisation and move towards Architectural awareness in the isolation quadrant, the picture
changes significantly. In this case the organisation appreciates its IT and its role is of strategic
import. This is also visible in the IT and business alignment that often takes place. The IT vision,
strategy and policy also match this effort. But in the isolation quadrant it is evident that
management loves IT, but the integration of IT within the organisation is poorly done.
Any organisation that is truly ready for a change in architecture is an organisation that is enabled
like described in the fourth quadrant. Organisations in this quadrant are able to utilise IT to its
fullest benefits. There is a clear vision of how to use architecture and this has already been
implemented through alignment with business management.
Architecture has been institutionalized and has become an integral part of the
functioning of the organisation. 34
Ø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

Another model although not from Dynamic Enterprise Architecture is the Jeanne W. Ross
model presented in MVTU’s hand-book. 35
It’s strategiske betydning

Lokal/Funktionel Effektivisering Proces- Strategiske
optimering af it optimering valg
Løsninger udenfor Forretningsudvikling
kerneområderne med lokal fleksi- Applikationer
bilitet
Lokal støtte af
Specifikke vidensarbejdere
forretnings-
Alle kerne-
behov Infrastruktur
processer
som services
Integration af
kerneprocesser
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

5.1.1 Strategic dialogue
The first step in the Strategic Dialogue is to determine the business objectives of the
organisation. Because developments in IT are so fast paced today, a company can no longer
make a strategic business decision and then hand it over to the IT managers and have them
figure out an IT strategy. It must be a common project, only when there is an integral
approach to the market and IT can the organisation make full use of all opportunities and
counter any threats.
To benchmark the company’s business objectives the S.M.A.R.T. way is always a good way.
Specific. The objective must be described in precise, specific terms.

Measurable. It must be possible to determine when the objective has been
achieved.
Acceptable. The organisation must be ready to work on the objective.
Realistic. It must be possible to achieve the objective.
Timebound. A time must be set when the objective is to be achieved. 36
ØS is increasingly becoming more and more responsible for architectural IT development

within the public sector, which necessitates ØS to develop some solid models and practices
to handle this responsibility. Their 5 strategic, architectural or business objectives do not in
many cases meet up to the expectations or criteria set by the S.M.A.R.T. rule-of-thumb. But
some of the solutions ØS create must be based upon public sector common standards, and be
specific and measurable to ensure their success. All agencies can see the benefit if a common
agreed-upon standard is chosen and this is very realistic to put into motion, it is after all one
of the main ideas put forth by the government too. 37
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
37
Arktitekturvision og –principper p. 5

fault of the method not of ØS. What it does not encompass is overall strategic and not very
measurable goals for a future project. One such strategic formulation by ØS is: Establish a
professional, systematic and coordinated approach for ØS as a market driver within the
public sector. 38 This statement is beyond the smart method’s simplistic or narrow scope,
because it simply is too strategic and lofty and not very measurable in terms of testability.
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

mistake of anybody working with organisational analysis is to focus on separate entities and
describe them, move on and describe the next. If this singular description is done properly
then the designers have “a proper and truthful” representation of the organisation. But
somewhere along gestalt gets lost in the description and the system works on paper and in
the organisation chart, but not for the people working with it everyday.
In some cases I could see Dynamic Enterprise Architecture be applied to test the
documentation gathered by designers. By applying a 20% effort to get a 80% result and have
a proper test scenario they would get an insight into whether or not what they gathered is a
correct representation or not.
It is a leap of faith or an arrogant approach (I believe the first naturally) to document such a
large organisation and still believe in the truthfulness of the gathered materials without an
actual test. A trial and error or iterative test-approach to information gathered and analysed is
a good sceptical approach. Know Thy Self. If gestalt 40 is lost then so is the long term use of
the system.
Obviously this is a very cumbersome tactic for an organisation this size, and ØS are planning
and working according to well-documented theories and methodologies. This in itself is not a
guarantee but one must also be pragmatic and realise that external factors like government
pushing for change in the public sector is also a heavy influence. In the end government is
the one paying the bills so they have the right to ask for results.
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
Translations from Danish to English:
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.

Dynamic Enterprise Architecture and Practical EA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dynamic Enterprise Architecture and Practical EA

Uploaded by

Copyright:

Available Formats

- T8 - Enterprise Architecture Spring 2006

Enterprise Architecture 4 week project

Dynamic Enterprise Architecture and practical EA

IT-University of Copenhagen spring 2006

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 1

1.1 AREA OF CONCERN 3

2 AGILITY AND COHERENCE 5

2.1 DYNAMIC ARCHITECTURE 5

3 “TEN” PRINCIPLES OF DYA 10

3.1.1 ARCHITECTURE IS STRATEGIC IF IT IS STRATEGIC 11

4 WORKING WITH(OUT) ARCHITECTURE 17

5.1.1 STRATEGIC DIALOGUE 25

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 2

1.1 Area of Concern

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 3

1.2 Motivation for EA initiative

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 4

2 Agility and Coherence

2.1 Dynamic Architecture

2.2 Potential of Information Technology

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 5

2.2.1 Tension and challenge

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 6

2.2.2 Wanted: Agile Architecture

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 7

2.2.3 Needed: Coherent Architecture

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 8

2.2.4 Dynamic Architecture: Architecture Aimed at Agility

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 9

3 “Ten” principles of DYA

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 10

3.1.2 Architecture must facilitate speed of change

3.1.3 Communication between business and IT management is crucial

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 11

3.1.4 Business objectives govern the development of architecture

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 12

3.1.5 Architecture must be developed “just enough, just in time”

The EA management plan is not meant to implement architecture by way of Big-Bang

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 13

3.1.6 Working under architecture is supported by a theoretical and working

3.1.7 Transparent relationships must be defined

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 14

3.1.8 Several development strategies are distinguished

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 15

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 16

4 Working with(out) architecture

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 17

Defensive Anticipative Offensive

Organisation is Organisation Organisation

Short-term solution Business- IT Short-term solution

To reach business objective quickly

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 18

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 19

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 20

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 21

Architectural awareness (on the left hand

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 22

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 23

It’s strategiske betydning

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 24

Specific. The objective must be described in precise, specific terms.

ØS is increasingly becoming more and more responsible for architectural IT development

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 25

IT-University, E-Business - Simon Kaastrup-Olsen - simkaa@itu.dk 26