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 - [email protected]

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


2


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 county1 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-book3 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.


3

- T8 - Enterprise Architecture Spring 2006 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


4


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 years6 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


5

- T8 - Enterprise Architecture Spring 2006 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 agile7 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.


6

- T8 - Enterprise Architecture Spring 2006 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-


7

- T8 - Enterprise Architecture Spring 2006 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

modules9.

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


8

- T8 - Enterprise Architecture Spring 2006 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,


9

- T8 - Enterprise Architecture Spring 2006 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 requirements12. 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


10


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 Dynamic Enterprise Architecture p. 54


11

- T8 - Enterprise Architecture Spring 2006 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


12

- T8 - Enterprise Architecture Spring 2006 strategy to fit within the scope of the government-defined one. This strategy is addressed in the

ØS visionary architecture16.

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 Repository18 - 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 plan19 - is concerned with how to specify

Common threads, Cross-cutting components and Lines of Businesses20. 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 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.


13

- T8 - Enterprise Architecture Spring 2006 Ø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-book23 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


14

- T8 - Enterprise Architecture Spring 2006 ØS decided that their documentation effort consisted of defining common denominators like

terms, actors, location and processes.25 On the below picture26 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


15

- T8 - Enterprise Architecture Spring 2006 strategy.27 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 Dynamic Enterprise Architecture p. 64


16


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.


17


Organisation is taken by surprise

IT solution: High ad hoc problem

Solving content

Short-term solution

Anticipative Offensive

Organisation chooses structural

solution

Organisation achieves one-off

competitive advantage

Short-term solution

IT solution: High ad hoc problem

Solving content

Business-organisation

IT organisation

Developmentprocess

Continous process

improvement

IT solutions: High anticipatory

content

To reach business objective quickly

Defensive

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.


18

- T8 - Enterprise Architecture Spring 2006 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.

time functionality

time

quality quality

functionality

money money

Variable Fixed Variable

Fixed

TRADITIONAL TIME-BOXING

To increase the speed with which applications are constructed, several new IT development

methods have been created such as DSDM(Dynamic Systems Development Method28) and

XP (eXtreme Programming29). 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 factor30, 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


19

- T8 - Enterprise Architecture Spring 2006 certain product is still going to pushed ahead, then the offensive or defensive strategy can apply

the MoSCoW princple31.

• 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 Dynamic Enterprise Architecture p. 155 32 Dynamic Enterprise Architecture p. 156


20

- T8 - Enterprise Architecture Spring 2006 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.


21


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.033 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

vision and policy on IT and architecture.

ØS themselves did not define the strategic

initiative, this was defined for them in the

white-book and the hand-book by MVTU.

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

to go ahead and start the initiative has not

been up to them.

Isolation

Enabling

Losing

Barrier

Integration in the organisation

Arc

hite

ctur

al a

war

enes

s

Low High

Low

H

igh

Model 1.0Integration 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


22

- T8 - Enterprise Architecture Spring 2006 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


23

- T8 - Enterprise Architecture Spring 2006 Another model although not from Dynamic Enterprise Architecture is the Jeanne W. Ross

model presented in MVTU’s hand-book.35

Applikationer

Data

Applikations-siloer ModulerEnsartededata

Standardiseret teknologi

Arkitekturmodenhed

Lokal/Funktioneloptimering

Strategiskevalg

Proces-optimering

Effektivisering af it

DatacenterData Warehouse

Fælles grund-databaser

Grunddatatilgængeligesom dataobjekter

Specifikkeforretnings-behov

Lokal støtte afvidensarbejdere

Løsninger udenfor kerneområderne

Forretningsudviklingmed lokal fleksi-

bilitet

TeknologiStandardisering

Integration afkerneprocesser

Alle kerne-processersom services

Infrastruktur

©2003 MIT Sloan CISR, Ross. Used with permission. All rights reserved.

It’s strategiske betydning

Applikationer

Data

Applikations-siloer ModulerEnsartededata

Standardiseret teknologi

ArkitekturmodenhedArkitekturmodenhed


Strategiskevalg

Proces-optimering



Strategiskevalg

Proces-optimering


DatacenterData Warehouse

Fælles grund-databaser

Grunddatatilgængeligesom dataobjekter

Specifikkeforretnings-behov

Lokal støtte afvidensarbejdere

Løsninger udenfor kerneområderne

Forretningsudviklingmed lokal fleksi-

bilitet

TeknologiStandardisering

Integration afkerneprocesser

Alle kerne-processersom services

Infrastruktur

©2003 MIT Sloan CISR, Ross. Used with permission. All rights reserved.

It’s strategiske betydningIt’s strategiske betydning

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


24


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 Dynamic Enterprise Architecture p. 76 37 Arktitekturvision og –principper p. 5


25

- T8 - Enterprise Architecture Spring 2006 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


26


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.


27


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


28

- T8 - Enterprise Architecture Spring 2006 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 gestalt40 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.


29


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/


30

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.


31

dynamic enterprise architecture and practical ea

Documents