Brian Kane Thesis EAI FINAL Public Version v3

8/3/2019 Brian Kane Thesis EAI FINAL Public Version v3

1/100

CONNECTING THE DOTS- Why Danish IT architecture does not result in interoperability -

BRIAN [email protected]

TUTORED BY

PROFESSOR MOGENS KHN PEDERSEN

Censored public version

.

Master of Science in Electronic Business

IT University of Copenhagen 2004


2/100

Executive summary ii

EXECUTIVE SUMMARYThe primary goal of this thesis is to consider how recommendations and standards for

Danish IT architecture, in general, assure successful systems integration, leading to inter-

operability in the Danish public sector.

The secondary goal is to assess the specific case of integrating ECM (ESDH) systems from

the FESD project with existing systems from KMD in the context of Danish municipali-

ties.

Danish IT policy states interoperability as its main objective for IT architecture work.

After examining the concepts of architecture, interoperability and integration, and study-

ing the case, we conclude on the current situation in terms of how mature the Danish

work on IT architecture is.

Core findings include:

Both the general standards and recommendations and the specific case of the

FESD project reflect an understanding of interoperability as being the exchange

of business documents.

Guidance on how to expose systems as services following the concept of service

oriented architecture is vague at best. Specifications are too broad and unspecific

to be implemented in a consistent manner.

There is no coherent way of resolving the physical or semantic problems when

two domains of control meet.

Most relevant standards are authorized for use, some overlapping and

conflicting, but no guidelines are in place for when to use which standards and

how.

Towards the goal of service oriented architecture, a sound underlying, perhaps

publicly controlled, integration infrastructure is needed.

There is a need for a long-term roadmap covering IT architectural efforts in the

decades to come. The roadmap should clearly describe the current IT

architectural situation, and include an explicit statement of strategic goals and

operationalized milestones.

While important work is being done at data model level, the task of moving data from

application to application is only vaguely described. In conclusion, Danish IT architec-

tural work can currently best be described as initial, informal and ad-hoc.


3/100

Contents iii

CONTENTS1.INTRODUCTION...............................................................................1

1.1.PROBLEM ................................................................................................................................1

1.2.CHRONOLOGY OF THE THESIS................................................................................................4

1.3.THE APPROACH......................................................................................................................5

2.WHAT IS IT ARCHITECTURE? ...........................................................72.1.WHY IS IT ARCHITECTURE IMPORTANT?...............................................................................8

2.2.IT ARCHITECTURAL INITIATIVES..........................................................................................10

2.2.1. Service oriented architecture.................................................... ..................................... 102.2.2. Ideal SOA illustrated.......................................................... ............................................ 13

2.2.3. Standardization............................................................. ................................................. 15

2.3.SUMMARY....................................................... ............................................................ .......... 18

3.WHAT IS INTEGRATION?................................................................193.1.WHY IS INTEGRATION IMPORTANT?....................................................................................20

3.2.TECHNICAL INTEGRATION...................................................................................................22

3.3.INTEGRATION MODELS.........................................................................................................24

3.3.1. Presentation integration model........................................ .............................................. 24

3.3.2. Functional integration model....................................................... .................................. 25

3.3.3. Data integration model................................................ .................................................. 27

3.3.4. Which model? .................................................... ....................................................... ..... 27

3.4.COMMUNICATION MODELS .................................................................................................28

3.5.INTEGRATION METHODS ......................................................................................................30

3.5.1. Message-oriented concept ............................................. ................................................ 30

3.5.2. Interface-oriented concept ................................................... .......................................... 31

3.5.3. Middleware types......................................................... .................................................. 32

3.6.ONTOLOGIES ............................................................ ............................................................ 32

3.7.LEVELS OF INTEGRATION .....................................................................................................36

3.8.SUMMARY....................................................... ............................................................ .......... 37


4/100

Contents iv

4.CASE:ECMKMD....................................................................384.1.THE ACTORS ................................................... ............................................................ .......... 38

4.2.FUNCTIONAL GOALS ............................................................................................................40

4.2.1. One way integration......................................... ........................................................ ...... 41

4.2.2. Two way integration ..................................................... ................................................. 42

4.3.ECM SYSTEM............................................................ ............................................................ 43

4.3.1. FESD project ........................................................ ....................................................... .. 43

4.3.2. Role of ECM.......................................................................... ......................................... 45

4.3.3. Software Innovation........................................................ ............................................... 47

4.4.KMD SYSTEMS .....................................................................................................................49

4.5.SYSTEM PORTFOLIO ..............................................................................................................51

4.6.PROBLEMS AND SOLUTIONS .................................................................................................53

4.7.PHYSICAL ....................................................... ............................................................ .......... 54

4.8.SEMANTICS ..................................................... ............................................................ .......... 57

4.8.1. Primary key................. ....................................................... ............................................ 57

4.8.2. Case concept.................................................. ........................................................ ........ 58

4.8.3. Solutions .................................................. ........................................................ .............. 59

4.9.SCENARIO:OPENING UP ......................................................................................................62

4.10.SUMMARY..................................................... ............................................................ .......... 64

5.ASSESSING THE STATUS QUO .........................................................65

5.1. E-GIF AND OIOXML..........................................................................................................66

5.2.FESD INTEROPERABILITY GUIDANCE ..................................................................................69

5.3.CASE:ECM SYSTEM............................................................................................................72

5.4.INTEROPERABILITY ...............................................................................................................73

5.5.ENTERPRISE ARCHITECTURE MATURITY.............................................................................74

6.CONCLUSION .............................................................................78

7.APPENDICES ..............................................................................80 APPENDIX 1:INTERVIEWEES .......................................................................................................80

APPENDIX 2:WHAT IS WEB SERVICES?.......................................................................................81

APPENDIX 3:THE STACK(S)-GAINING A VOCABULARY ...........................................................83

APPENDIX 4:STANDARDS MAP...................................................................................................90

8.BIBLIOGRAPHY ...........................................................................92


5/100

Contents v

Boxes

Box 1: Business document exchange ......................................................... ................................ 31

Figures

Figure 1: Problem...........................................................................................................................2

Figure 2: Problem, and feed-back ....................................................... ......................................... 4

Figure 3: Past, present and future................................................................................................6

Figure 4: Ideal SOA, logical 1 ................................................................... .................................. 13

Figure 5: Ideal SOA, logical 2 ................................................................... .................................. 14

Figure 6: Ideal SOA, physical ....................................................................... .............................. 15

Figure 7: Presentation integration model ................................................... .............................. 25

Figure 8: Functional integration model.....................................................................................26

Figure 9: Data integration model ............................................................ ................................... 27

Figure 10: Request, reply.............................................................................................................28

Figure 11: Star typology ........................................................ ...................................................... 48

Figure 12: Systems grouped by vendor.....................................................................................52

Figure 13: Basic integration scenario.........................................................................................54

Figure 14: Integration model possibility ..................................................... .............................. 55

Figure 15: Case concepts ............................................................ ................................................. 59

Figure 16: Data set filtration ............................................................. .......................................... 63

Figure 17: Problem, again ......................................................... .................................................. 65

Figure 18: IT architecture to product.........................................................................................65

Figure 19: Conflicting logics ........................................................... ............................................ 68

Figure 20: Formal, de facto and proprietary.............................................................................70Figure 21: Application level standardization...........................................................................71

Figure 22: Integration model standardization..........................................................................71

Figure 23: Sample WS network ................................................................. ................................. 82

Figure 24: The W3C WS Stack ......................................................... ........................................... 83

Figure 25: SOAP message ......................................................... .................................................. 85

Figure 26: Publish, find & bind ..................................................................... ............................. 88

Figure 27: Engaging a WS ........................................................... ................................................ 89

Figure 28: Standards Map...........................................................................................................91

Tables

Table 1: Service oriented architecture contrasted ................................................................. 11

Table 2: Levels of integration......................................................................................................36

Table 3: Goals for ECM systems.................................................................................................40

Table 4: Level of compliance (physical) ............................................................. ....................... 56

Table 5: Integration model pros and cons.................................................................................56

Table 6: Level of compliance (semantic) ...................................................................... ............. 61

Table 7: Conflicting inter-process communication standards................................................66

Table 8: Assessing enterprise architecture; integration. ......................................................... 75

Table 9: EDI vs. Distributed Object XML Paradigms..............................................................87


6/100

Introduction 1

1.INTRODUCTIONWork on IT architecture in the Danish public sector has intensified dramatically in the

past few years. A focus on a more holistic view has emerged, along with a trend of look-

ing at how we can break down the barriers between IT systems, and reap the benefits of

thinking across traditional divides.

Last summer, in June 2003, the Ministry of Science, Technology and Innovation published

a milestone white paper on enterprise architecture, thus putting these issues firmly on the

agenda.

The first two paragraphs of the white paper sum up the goals for the work:

E-government is largely a matter of getting public sector IT systems geared to inter-operability. The authorities must have the capability to use each other's data so thatcitizens, companies and case officers do not have to provide and check the same infor-mation over and over again. This requires, for example, common data definitions andcoherence in the handling of security and users. And it means dispensing with 'tech-nological islands' if we are to create a platform for new work practices.

In this regard, a coherent enterprise architecture framework in the public sector is animportant factor. Like a number of other countries, Denmark has now placed enter-prise architecture high on its agenda because through enterprise architecture it is pos-sible to govern the organisation and interoperability of IT systems. This is the back-ground to this White Paper on the principles for a common public sector enterprisearchitecture. (Ministry of Science, Technology and Innovation 2003)

Since the publication of this paper a year ago, there has been increasing interest in the

subject. Is this much ado about nothing? Definitely not. This is the core strategy for the

inner workings of the nervous system for the whole public sector in Denmark, and will

influence the way we work and live, and not least the competitiveness of Denmark and

the individuals and firms that are located here.

Although the White Paper does try to give practical advice on some points, it is mainly a

policy paper that sets out the strategic focus on IT architecture.

In this thesis, I will examine how the goal of IT systems geared to interoperability isimplemented in an actual project, and by doing that, perhaps learn where we can inten-

sify efforts to ensure that we reach that goal. We want to learn whether the strategic goals

can actually be operationalized.

1.1. Problem

The Danish public sector is intensifying its efforts in e-government. While being a rather

small country, Denmark has practised a policy of relatively decentralized power, and it

has therefore not been very eager to dictate things to the lower levels of public admini-

stration. This is changing as awareness is growing of the fact that some form of central


7/100

Introduction 2

planning of the IT architecture is needed. The classic example is to draw a parallel to city

planning, which is a widely used metaphor for describing IT architecture and processes

surrounding it. It is a very effective way of describing the need for central control or

coordination, as nobody in Denmark would dream of allowing city planning to be uncon-

trolled. At any rate, there is now political motivation behind the rhetoric, and things aremoving. Standardization is the basic building block for many of the goals that (almost)

everyone agrees on, like being able to heighten efficiency by allowing systems to com-

municate and expanding offerings and services to the customers: Danish citizens and

firms, and other public organizations.

The main goal of this paper is to present an analysis of the relationship between IT archi-

tecture recommendations and standards on the one side and, on the other side, actual

integration resulting in interoperability. This is plainly illustrated in Figure 1.

Figure 1: Problem

The central question that this thesis will seek to answer is therefore:

How do Danish IT architecture recommendations and standards ensure integration and

interoperability in public sector organizations?

One of the most highly profiled projects at present, second only to the Virk project, is the

project called Fllesoffentlig Sags- og Dokumenthndtering1 (FESD). FESD sets out to

become the standardized way of handling enterprise content management (ECM, in

Danish called ESDH). When developed, vendors will be able to certify that their productscomply with the standard, and will be able to label their products as such. The vision is

that these systems should be at the core of much of public sector work, coordinating case

work and decision-making processes across organizational boundaries. The FESD project

is supposed to be a prime example of the practical implementation of the vision for e-

Government.

A major criterion for the success of the FESD standard is the handling of existing systems

in place in organizations, which have to be integrated with the ECM systems from the

1 See www.e.gov.dk/fesd


8/100

Introduction 3

FESD work. Obviously IT systems are found at all levels of the public sector from local

authorities in the Danish municipalities to state level. As we move towards a more coor-

dinated perspective, we face the inevitable problems that stem from that view; we have a

myriad of heterogeneous systems that have not considered each others existence before

now, and therefore have different ways of defining things, and employ different con-cepts. The situation today could, in one word, be described as inconsistent; there is a

great need for coordinating IT architecture. The existing systems will not be replaced in

the short term. This means that any new public IT project has to carefully consider how to

handle its co-existence with systems already in place.

As one of the main arguments for introducing ECM systems is to improve efficiency, it

would not be true to the cause to ignore the issues of integrating new systems with exist-

ing ones. And I dare say it has not been ignored; this problem has spurred a lively debate

in the trade press lately, but no one way forward seems obvious. One of the most press-

ing problems in terms of sheer volume is the integration to the existing systems in the

Danish municipalities. The municipalities are important because they have a lot of case

work, so having two systems that overlap and are not integrated would not be appreci-

ated. The current situation is that a Danish vendor, KMD, has the lions share of the mu-

nicipalities market and has a huge portfolio of systems. KMDs products are widely used

by the municipalities, and there is heavy vendor lock-in to KMD.

The needed capabilities of the municipalities are shifting and evolving, and moving

towards needs not currently provided by KMD, needs that KMD is working towards

providing, but is playing catch-up to the smaller vendors in the FESD project. Earlier,

KMDs position in the market, essentially one of monopoly, allowed the firm to partially

dictate trends and offerings to the municipalities. This situation is changing as we now

see more clear demands on the part of the municipalities, and we are seeing a clear inter-

est among municipalities in the ECM systems coming out of the FESD project.

This poses a problem for the municipalities as to which path to pursue. There is a need

for the municipalities to have a clear strategy for their IT architecture, specifically for the

integration of ECM systems from the FESD project into their existing portfolio of systems

from KMD. But since the FESD project should adhere to central IT architecture guide-lines, a lot of the strategy should already be mapped out.

We will look in detail at the FESD project, and the challenges posed by integrating an

ECM system from the FESD project with other systems, and conclude on the appropri-

ateness and completeness of the Danish IT architecture work.


9/100

Introduction 4

I have interviewed representatives of all the central actors2 in my case, principals from

KMD, the FESD project, the municipalities and the FESD vendors who are developing the

actual FESD systems. They have all spoken about the situation, what the issues are, what

goals they see, and so on. They unanimously view the issues of IT architecture and inte-

gration to be among the most important in moving the public sector forward. In thissense, they all agree. There is some apprehension to be detected; representatives of the

municipalities and KMD are especially worried about the actual feasibility of current IT

architecture recommendations in making concrete integration possible.

This thesis will examine the specific case of integration in the Danish municipalities be-

tween ECM systems from the FESD project and existing systems from KMD. This specific

case will show us how IT architecture standards and recommendations trickle down to

the actual implementation of an IT project. Figure 2 simply shows how I hope to draw

conclusions as to the state of IT architecture on the basis of the specific case. It will later

become evident why there is not a problem of induction in this argument, although it

may appear so now.

Figure 2: Problem, and feed-back

During my analysis of the case I will make concrete recommendations on integration,

specific to the case. So the product of this thesis will be twofold. Firstly, it will result in an

evaluation of IT architecture initiatives, and, secondly, it will result in a proposal for a

solution to the actual integration between the FESD systems and systems from KMD in

Danish municipalities.

1.2. Chronology of the thesis

Let me present the layout of this thesis, and how the individual parts fit together. The

central question for this thesis, as I have defined it above, has two main concepts, IT

architecture and integration.

2 Interviewees represent the case and not the general findings of the thesis directly. I have listedinterviewees in an Appendix 1, page 80. I generally do not quote interviewees directly, since anappreciation of the situation cannot be found in a few sentences. When I do rarely make a directquote, I will provide a time reference to the sound recording associated with the interview. Re-

cordings of interviews have been made available at http://xxx.xxxxxx.xxx (user: xxxxxx, password:xxxxxx), but please appreciate that some of the material is quite sensitive, and strictly for personallistening and that it is not for distribution in any form.


10/100

Introduction 5

In chapter 2 I will unfold the first of those concepts, looking at what architecture is, what

the point of IT architecture is, and try to take a closer look at one of the most central

concepts of IT architecture strategy, which also has a prominent place in the White Paper,

that is Service Oriented Architecture (SOA). I will also be looking at other IT architecture

standards and current initiatives.

In chapter 3 I will present the other main concept: integration. We will see why we are

concerned with integration, and we will be looking slightly more in-depth at the technical

issues that have to addressed, and also at models for understanding integration scenar-

ios.

Moving on, in chapter 4, I will look at the specific case of integrating a system from the

FESD project with existing systems from KMD in the context of Danish municipalities.

We will be drawing on the concepts outlined in chapter 3, to understand what problems

exist and how we can tackle those problems.

Ideally, IT architecture standards and guidelines should influence the FESD project,

which should in turn influence the ECM system coming out of the FESD project and

make sure it is able to handle integrations. In chapter 5, I will try to examine lessons

learned from the case in chapter 4, and see whether there is a relation between the three

elements: IT architecture standard, the FESD project and actual ECM systems.

Lastly, I will conclude on my findings.

1.3. The approach

I would like to make it very clear that I am not trying to explain why the situation is as it

is, merely explain what the situation is, and what consequences it has. As seen in Figure 3,

I divide the problem into past, present and future. Understanding the why is about un-

derstanding the dynamics of the complex context. How do the players influence the

arena, what capabilities do they have, how is public opinion dictated, and so on. These

are very messy questions, which do not lend themselves easily to structured analysis,

and I will not be answering them. The past is complex in the sense that it is a black box of

intricate relationships between the involved parties and their surroundings. I have usedarrows in the figure, but they do not indicate causal relationships. The past cannot be

analyzed clinically and be subjected to formal logical reasoning, since we do not have

access to it, and, because of its nature, it is a mixture of political goals, business strategy,

scarce resources and honest goals for making the Danish public sector work better. To try

to give a meaningful presentation of an alleged causal relationship between these influ-

ences is utterly meaningless.


11/100

Introduction 6

Figure 3: Past, present and future

The present, on the other hand, is relatively plainly visible. We can see what the situation

is with regard to integration, available documented standards, actual initiatives, what

capabilities the parties have, and so on. Here we have an actual situation that can be

viewed to some extent. Here I lean towards realism; there is a world and it may be ob-

served and examined, or in other words, I feel that we can look semi-rationally at the

situation and again semi-rationally map out a course of action stating pros and cons. This

does not mean that the present is simple; it just means that it is not as meaningless to look

at, and in fact we may be able to say something reasonable about it.

Again, the future is complex and therefore unknown to us. It might even be more com-

plex than the past, but we might be able to speculate on some possible scenarios, and try

to look at a few what-ifs and contemplate possible routes.

I do not consider there to be one truth or reality when talking about the problems that

occur in the cross-fire of politics and strategy. Understanding the complex parts is a very

important dimension nonetheless, since this is the basis for understanding the motiva-

tions of the players and perhaps understanding how to influence the scene, once we have

diagnosed the problem, if in fact there is one. But again, I will not be working with that

issue. Naturally there are conflicting interests in the snapshot of the present as well as the

more complex past and future, and these must be weighed along with the influence

assigned to issues such as overlapping or incomplete standardizations, to name but one.

But without further ado, let us begin with IT architecture.


12/100

What is IT architecture? 7

2.WHAT IS IT ARCHITECTURE?IT architecture is not much different from ordinary architecture at the superficial level.

Merriam-Webster defines architecture as a: formation or construction as or as if as the

result of conscious act. b: a unifying or coherent form or structure. Architecture is noth-

ing new. It is not new to the public sector. We have had architectural plans at application

level for a long time, but the difference is a change in scope. When we say IT architecture,

we think of a broader plan for how the individual parts should fit together. We are taking

the birds-eye perspective, and want to create a coherent form or structure for all the bits

we see in that perspective.

Perhaps the best picture of the ideal scenario would be if all players agreed on architec-

tural goals and basic foundations. In a private organization it is natural to have one mas-ter plan for architectural work. If everyone acted as one concerted whole, we would

move towards the ideal situation. I do not want to make the point that the Danish public

sector could in general be regarded as a private organization. But in this case it seems

appropriate to draw parallels. We do not want to build cathedrals and dictate decentral

doings, but we do want strong coordination of what goes on.

Often IT architecture is compared with city planning. The reason for this is that in IT

architecture, like city planning, you need to have some elements that would not be de-

veloped decentrally if not coordinated. Like waterworks, roads and telecommunications,there is a need for an infrastructure which would not simply emerge out of the organiza-

tions normal operation. The individual standards might not suit everybody; to some, the

train tracks might initially be too narrow or too wide, but in time we agree on a certain

width, and all trains can go on all tracks, which is a good thing when we want to achieve

maximum flexibility and efficiency. Not all things have to be standardized. Usually you

operate with different levels of standardization; some standards might be global, mean-

ing in the whole sphere of control or influence of the standardizing organ. Some stan-

dards might be regional, either in a geographical sense or more often in a logical sense;

with regard to certain types of objects one standard may apply and for another group ofobjects a different standard applies. And lastly you have local standards, which could

simply be conventions within one organization or department. These, you could argue,

are not really standards at all, since only one party uses them, but we wont quibble over

words. The reason for differentiating between global, regional and local standards is that

it is simply the most efficient approach. We constantly have to keep in mind what the

purpose of standardization is: to make life easier for us. When certain standards are

irrelevant for others to know about, there is no reason for standardizing. This is all very

general, and to get a more detailed picture we should dive into some examples, which we

will do, after discussion why IT architecture is important.


13/100


2.1. Why is IT architecture important?

The world we live in is changing. Organizations are forced to adapt to this. Weick pre-

sents the notion of "loosely coupled" organizations, using educational organizations as

examples. He argues that although certain actions or events may seem "irrational," it is

often because the rules of the game are not defined.

Imagine that youre the referee, coach, player or spectator at an unconventional soc-cer match: the field for the game is round; there are several goals scattered haphaz-ardly around the circular field; people can enter and leave the game whenever theywant to; they can throw balls in whenever they want; they can say thats my goalwhenever they want to, as many times as they want to, and for as many goals as theywant to; the entire game takes place on sloped field; and the game is played as if itmakes sense(Weick 1976)

We do not fully understand what is going on, but this is the world we are in, and we

must learn to deal with it. IT architecture is about being consistent in the way you deal

with sloped playing fields. Some years ago I read a book by Marshall Berman called AllThat Is Solid Melts into Air. I really like that title, and I think of it often when consider-

ing development trends. The book is basically about how modernity is much more cha-

otic than we think. Modernity has been made out to be an exponent of the rational, but

here it is presented as a process that cannot be finished. I think it also applies to the de-

velopment in the way we want information systems to behave, and to some extent it also

applies to what we want from an organization. Let me explain.

Historically, our information systems have been designed in the broadest sense of the

word. By that I mean that someone has had a vision of what they wanted to achieve.They have formulated goals, designed specs and proceeded to develop and implement

these. This process assumes that it is possible to know what capabilities you will need in

the future, and that it is possible to intellectualize those assumptions of the future into

some sort of model of what we want to achieve.

Being able to know what capabilities we, as an organization, need to have in the future is

becoming more and more difficult. This motivates a move from the formulation of capa-

bilities as something concrete towards the abstract or what you might call meta capabili-

ties. This is less relevant on the strategic level, since goals are already on a meta level, butmore true towards the operational side of things.

All our solid and concrete beliefs of what we need in the future melt into the unknow-

able, chaotic and creative. But this is just my opinion. Luckily it maps quite conveniently

onto the very practical types of functionality that organizations have been looking for

and which vendors are happy to provide. At a cost, naturally. Therefore we see formula-

tions of necessary capabilities like flexibility, which is very abstract.

Managing competitive advantage today means to some degree adapting faster than your

competition rather than seeking a stable and long-lasting niche. When speed grows instrategic importance, the IT infrastructure should grow accordingly, to match it. This is


14/100


where we need technology to help us. Providing the hope for more flexible, faster adapt-

ing, and more distributed and integrated organizations, technology might be one of the

tools used to keep abreast with the competition. This is not to argue that speed and

adaptability alone will give you an edge, but simply that it is a necessary, not sufficient,

premise towards obtaining competitive advantage. The markets seem to be moving at anever increasing speed, and therefore this has become a very important separate capabil-

ity. As we all know all too well, there was a trend of talking about core competencies etc.

some years ago, and the resulting need for decoupling and partnering, as it is some-

times called.

IT architecture is important for many reasons. As the world around us changes, so must

we change our priorities; we are seeing a shift from prioritizing decentral control and

decision making towards prioritizing adaptability, flexibility and efficiency. Because we

want to be able to keep up with the speed of the world around us, IT architecture be-

comes relatively more important than it has been earlier.

The economic environment in which businesses find themselves today is perhaps themost turbulent in history. It is dominated by three powerful influences: globalisation,a knowledge and information revolution, and structural change. (Scott, Comer1999:130)

only those enterprises that realize the necessity of being able to access internal andexternal data quickly, to integrate and manage this data effectively, and to make itavailable both within the company and externally over the Web will be able to main-tain and extend their lead over their rivals. (Shi, Murthy 2003)

The quote from Scott sounds a little dated, but is nevertheless still relevant. Shi concludeson the consequences of the current situation for organizations and the need for free-

flowing information. The public sector, especially in social welfare systems such as the

Danish, is influenced greatly by these developments. These are the circumstances the

Danish public sector has to come to terms with. Back in 1985, Porter (Porter, Millar 1985)

already said that that information and movement of information is important for the

competitive landscape.

The information revolution is affecting competition in three vital ways:

It changes industry structure and, in so doing, alters the rules of competition.

It creates competitive advantage by giving companies new ways to outperform

their rivals

It spawns whole new businesses, often from within a companys existing

operations

The point Porter is making is that connecting information gives a whole new dimension

to the market. Bringing things down closer to actual IT architecture, an important article

in Harvard Business Review (Hagel, Brown 2001:109) a few years ago posed the fivecentral questions CIOs and CEOs must ask themselves:


15/100


Does our management team have a shared vision of the long-term (five to ten

years out) business implications of the new IT architecture?

Do we have a transition plan that balances the state of the architectures

development with a clear understanding of the areas of highest business impact?

Are we moving fast enough today to build our expertise and exploit immediate

opportunities for streamlining intercompany processes, outsourcing activities in

which we dont have distinctive capabilities and designing Web services that we

can market to other companies?

Do we have a clear understanding of the obstacles within our organization that

may hinder us from exploiting the full value of the new IT architecture, and do

we have initiatives under way to overcome these obstacles?

Are we exerting sufficient leadership in shaping both the functionality offered by

providers of Web services (defining, for example, the performance levelsrequired for mission-critical applications) and the standards needed to

collaborate with our partners?

This thesis will take questions such as these as its backdrop for looking at Danish public

sector practices in IT architecture.

2.2. IT architectural initiatives

In the following we will explore the main government initiatives on IT standardization

and recommendations. This will give an image of which issues are being worked with,and what priorities are evident. Before we dive into actual initiatives like the OIO XML

work and the Danish version of an e-Government Interoperability Framework (e-GIF) we

will look at service oriented architecture, which is a central concept defining much IT

architectural work these days, both in the public and private sector.

2.2.1. Service oriented architecture

One of the most central concepts laid down is what is called Service Oriented Architec-

ture (SOA). It is Danish public policy for systems to be developed to adhere to service

oriented architectural principles.

The core of this common public sector architecture work is the choice of the service-oriented architecture model, which defines the interoperability between IT systems asservices offered by one system component and used by another.(Ministry of Sci-ence, Technology and Innovation 2003:31)

Because this is such a central theme, we will spend some time examining what SOA

means, to understand how it should influence the practical work with IT architecture. It

is important from the start to stress that SOA is not a standard, and is not tied to a specific

technology. SOA is a concept that can be implemented with various technologies (but

they naturally have to be suited for the task). SOA relies on the term services:


16/100


A service is a function that is well-defined, self-contained, and does not depend onthe context or state of other services. (Barry 2003:19)

The following Table 1 is taken from the White Paper (Ministry of Science, Technology

and Innovation 2003) which contrasts SOA against what is seen as other paradigms.

Mainframe Archi-tecture

Client/server Ar-chitecture

Service OrientedArchitecture

Platforms Monolithic andcentralised

Homogeneous andcontrolled

Diverse and unpre-dictable

Networks Restricted andclosed

LANs widespreadbut isolated

Internet, omnipres-ent and linked

Data Formats Non-transparentand inaccessible

Binary and proprie-tary

Semantic and di-vided

Technology Focus Operating system Database Interface

Users IT operators Case officers Suppliers, employ-ees, custom-ers/users

Business Value Digitalisation ofdata-centric opera-tions

Provides data tousers

Promotes businessagility, adaptabilityand interaction.

Table 1: Service oriented architecture contrasted

A real world system is likely to have elements of all three archetypical architectures we

see in the top row of the table (as well as other, less crisply defined architectures), so

naturally it would not be as clear cut as we see here. However, for the sake of simplicity, Iwill briefly take you through the right-most column and interpret what is meant. The

importance of this lies in SOA as the main definition of the ideal architecture, so it is

crucial to understand what we mean by it. On the platform level the word unpredict-

able is used. As a consequence of a fast-moving world where enterprise adaptability is a

sought-after competency, organizations must change their fundamental outlook on the

world. We touched upon this in previous sections. One might even call the unpredictabil-

ity an adoption of a new ontology (in the classic sense; assumption of how the world

works, etc.). Earlier, in IT architecture, we have seen a heavy consensus on planning and

control. This approach, as I understand it, has the essential premises that 1) you canforesee the future and what needs there will be 2) you can embed the assumptions re-

garding the future into a system you have control of.

I imagine these ways of thinking stem from a mechanical image of the world, but they are

proving less and less useful. The reality of today is that you cannot as clearly or easily

predict what the future will bring. The horizon is moving ever closer. This is increasingly

true as the viewer and the viewed are further apart, or in other words it becomes more

difficult to make predictions in decentralized organizations. The second assumption is

about control. It is not viable to assume that a central power has supremacy in a specificinteraction. This is quite obvious when we think of how cross-organizational business


17/100


processes are becoming the norm, and how the on-demand movement requires real-

time interaction between different systems. So what do we do to address this changed

landscape? SOA to the rescue.

The platforms in SOA thinking have to be thought of as distributed application. In the

coming sections we will be illustrating this in more depth, so do not despair if it does not

make perfect sense now. Web services is a specific technology that can be used to imple-

ment the concept of SOA. With SOA you distribute your application across physical and

logical divides. There is a tricky question of definition here, because the point of SOA is

also that you can use functionality (services) that are outside your realm of control or

ownership. So the borders of an application become very fuzzy. One service could be

viewed as a little application in its own right or as a subpart of all the applications which

that service is a part of. In theory you could imagine building an enormous number of

applications using a static number of services that are aggregated in different ways. As

opposed to earlier, SOA is a much more organic platform, where elements can be added

and used continuously, with no central power having a final say or absolute control.

It is ideas like SOA that are the basis for the need for integration technology because

when we decide to split up the elements of an application we need to tie the little bits

back together again. This is where middleware, brokers, etc. come in, which we will learn

about in the next chapter.

Moving on to the network level in the table, we find much more familiar concepts. We

have long been conditioned to see the advantages of one big internetwork, which hasbeen designed to be resilient to faults. The physical infrastructure of the public internet

that underlies SOA thinking at the platform level has been around for some time, and has

long since adopted the distributed thinking that made it so attractive to the American

defense.

As for the next dimension of SOA from the table, technology focus, they use the term

interface. In this context interface must mean machine-to-machine interface and not a

user-oriented interface, as you might think. Obviously when applications have to interact

more and more, there is a need to focus on the interface they expose to other systems.

This does not mean that you can pay less attention to the operating system or the data-

base. The database design also becomes more critical since you have to take the integra-

tion issues into consideration when you design it (providing you can know anything

about the integration needs at design time).

With regard to users, I would not say that SOA thinking places less emphasis on internal

employees, but simply broadens the field of vision to include other parties in the (infor-

mation) supply chain, who previously were not as interesting to consider.

The business value box is what its all about, and resembles what I started out with in mypresentation of SOA. The consequences of implementing SOA, ideally, should be faster


18/100


moving organizations. This could mean a faster moving supply chain which has lower

switching costs, faster prototyping of new products, greater adaptability to market trends

or greater accountability, to name just a few possible positive consequences.

2.2.2. Ideal SOA illustrated

Clearly we do not live in a perfect world. Nevertheless, I will now try to describe what an

ideal SOA means. In an ideal world we move towards true SOA, in which all parties

adhere to the same conventions. To try to show this, I have tried to develop some illustra-

tions of what adopting SOA means. There are two logical illustrations and one physical

illustration. The logical illustrations show how the architecture can conceptually be

thought of, while the physical illustration is closer to infrastructure level.

Figure 4: Ideal SOA, logical 1

In Figure 4 we see a snapshot of a scenario. Here we see a logical representation of high

granularity web services (the smaller circles) being parts of a larger granularity web

service. The inside part of the rings both the smaller and the large symbolizes a spe-

cific, perhaps legacy, platform, while the outside band symbolizes a standardized inter-

face towards the outside. This picture illustrates the hierarchical relationship between

applications published as web services that will always exist at any time. So we have a set

of applications of different size that are aggregated into more and more complete appli-

cations. The groups of circles that do not connect symbolize systems which are not inte-

grated in any way. The smallest applications could be simple services providing banal

functionality like basic arithmetic functions, while the largest circle could be the entire

network of applications. Using this method, applications used in multiple instances

would simply be depicted multiple times. This could be described as a static state view.

In relation to our ideal scenario, this figure describes one way the system should be able


19/100


to be described when SOA has been implemented. Notice that even systems of the same

type should in principle communicate using the shared standards (the outer ring should

be in between).

The next illustration of an ideal scenario is more of a map, trying to give an overview of

the application chunks and their relationships. Here each web service is only depicted

once.

Figure 5: Ideal SOA, logical 2

Notice again how the applications that have different insides externally provide a consis-

tent way of accessing the insides. It is clear that the concept of an application begins to

crumble here. What we call an application is simply a matter of choosing to draw a circle

around a group of circles/applications. Being able to draw this map of our systems

would indicate something close to the ideal.


20/100


Figure 6: Ideal SOA, physical

In the physical depiction of an ideal scenario, we can see that the many-to-many connec-

tions of the logical illustration have been replaced by a star typology with central hubs. In

practice it would not be efficient to physically make point-to-point connections between

all endpoints. In theory this is possible, but it would be too expensive to administer and it

would not allow for much central coordination.

In this illustration the satellites are the applications. The different patterns indicate

different platforms, standards, etc. The hubs act as brokers between the different native

ways of communicating and the internal lingua franca. Communication between hubs

happens via an open shared network in the common and standardized fashion.

To understand the way the different illustrations supplement each other, you could relate

this to the difference between the physical internet and the distributed peer-to-peer ap-

plications that run on it. The analogy only partially holds water but it might help to

give an impression of the difference.

You should now have an idea of the distributedness that is central to the idea of SOA. In

my presentation of SOA, I have assumed that we were dealing with different platforms,

protocols, etc. (hence the different patterns in the figures), but this may not always be the

case. Standardization work could help iron out the differences between systems, if we

should choose to take that path. We turn now to standardization.

2.2.3. Standardization

Standardization as an IT architectural effort is supposed to be an essential part of making

integration possible. We earlier distinguished between global, regional and local architec-ture work, and we must remember that many standards are global in the literal sense;


21/100


they are supposed to be used consistently everywhere in the world. These standards are

usually quite generic in that they can be used for all sorts of things (e.g. the standard

XHTML 1.0 does not dictate what the web page presents). These standards can be influ-

enced via committee work in the standards organization, and we do have Danish repre-

sentation on several committees, but it would not make much sense to invent a Danishstandard if there is a global one covering the same area. Standards organizations are

naturally influenced heavily by industry, so there is a lot of politics and market powers

involved. This means that several standards organizations come up with rivalling stan-

dards that do basically the same thing, but usually have a bias towards a specific vendor,

normally Microsoft, Sun or IBM, to name a few. Standardization work, on the generic

level, is thus primarily about choosing between rivalling standards.

In the context of this thesis, we are talking about integration leading to interoperability,

so let us narrow our scope a little. With respect to standardization of integration tech-

nologies, we must make an important distinction. I differentiate between two basic strate-

gies: converge and connect. By converge I mean to make heterogeneous systems homoge-

neous, or put differently, to make detailed standardization of actual technologies that

are the systems. Connect means to standardize on the meta-technologies that leave the

heterogeneous systems as they are, but dictate how to link the systems together, how to

approach the problem and to overcome the differences in a structured and consistent

manner.

Standardization of actual technologies is a long-haul strategy, because it means altering

systems already in place. That translates into an expensive strategy in the initial phases,

but when it is completed, many things will become easier.

Standardization of meta-technologies and approaches, which does not dictate actual

standards but helps us to address the differences, lets us tolerate existing systems, and to

some degree encourages the differences. An argument for a connect strategy would em-

phasize that there is a reason for systems being different; this is not accidental. Systems

express and reflect the context they are in, and are therefore appropriate.

Now we will turn to a very brief presentation of the two main initiatives for IT architec-

ture that are relevant to the question of interoperability. There are other initiatives such

as standard contracts and benchmarking work which are also parts of good IT architec-

ture practices, but not relevant to our questions of interoperability. We will be returning

to an actual evaluation of the initiatives after we look at our case.

e-Government Interoperability Framework

In order to achieve a shared platform of standards, a working group has set up the e-

Government Interoperability Framework(Det Koordinerende Informationsudvalg 2004)

which makes recommendations on the global standards. An e-GIF defines the standards

used in public government. Many countries have an e-GIF, although these vary in terms


22/100


of the role they play and how detailed they are. This will not be an extensive investiga-

tion into the (at present, 107 different) actual standards listed in the Danish e-GIF, simply

a statement of its purpose. The recommendations in the e-GIF are meant to help projects

and organizations make choices that are not aimed at the specific problem in the project

but are meant to serve a larger good; it might be a disadvantage for the individual projectto use a specific standard, but they should use it because it has been chosen as the com-

mon standard. The e-GIF recommends on a whole range of issues3, some of which are

more relevant to our context than others. A lot of the standards are quite banal since you

would not consider using anything else (like TCP/IP and JPG) so these are obviously not

of much use.

We will make an assessment of the e-GIF at a later stage, when we have more insight into

what we should expect to find there.

OIO XML

OIO XML is perhaps the biggest and most important architectural work done yet in

Denmark.

The main purpose and value is to support exchange and reuse of data related to pub-lic and private service delivery, including cooperation, business reengineering andalignment of related services. (National IT and Telecom Agency 2004)

The important part of OIO XML work is that it aims to document what information exists

in what systems in the public sector. The way that this has been done has basically been

to convert paper based forms and data models from databases to XML Schema 4. XML hasmeant that this task is significantly easier to do than earlier. With XML being so widely

adopted as a structured messaging format, we suddenly have a consistent way of de-

scribing our data and constraints on the data, the XML Schema. This means that we do

not have to agree on all the details of the structure of a message bilaterally between each

set of communicating points, but we can all simply say we adhere to the same specific

XML Schema (not quite that simple, but nonetheless). With OIO XML we ideally know

exactly what information exists in the various public offices, and this work can therefore

form the basis for a unified view of the public sector.

Obviously we still have to agree on the semantics we have to agree that when we wrap

an element in the tag street, that the receiving party agrees that what we call street is

just that, and not street name or something else. This issue is quite an important one in

integration problems, and we will examine it more closely in section 3.6.

3 If you are not familiar with this work, I suggest you go to http://e-governments.org/referenceprofilen/ now, for a quick look4 See http://www.xml.com/pub/a/2000/11/29/schemas/part1.html


23/100


As a message format, XML provides the flexibility we have long been looking for and is

the basis for countless standards, most noticeably the whole family of web services re-

lated standards, but in our case those for describing data in particular.

There are related committees that work on issues that use XML. These include for exam-

ple the DokForm5 work which was initiated some years ago. This work is still in its initial

phases, but is focused on metadata for ECM systems, which essentially means choosing

the right descriptors for a case in an ECM system, the argument being that this would

allow for easier exchange of case data.

Again, we will return to the OIO XML, and an evaluation of it in particular, when we

have learnt how it fits into the bigger picture.

2.3. Summary

In this chapter we have looked at a central concept which is supposed to define Danish IT

architecture strategy: service oriented architecture. We have seen how this means a much

more distributed way of thinking and involves abandoning the silo-mentality often ob-

served. We have then looked at two essential and more concrete initiatives: OIO XML

and e-GIF, where OIO XML maps the information in existing systems using Schema and

where the purpose of e-GIF is to aid us in making choices leading to standardization

covering both a connect and converge strategy.

5 See http://www.oio.dk/XML/standardisering/dokform


24/100

What is integration? 19

3.WHAT IS INTEGRATION?Every time a closed system opens, it begins to interact more directly with other exist-

ing systems, and therefore acquires all the value of those systems. (Kelly 1999)

In the following sections we will take a look at the business goals of integration efforts,

which cover the broad arguments for thinking of integrating systems. After that we will

look at technical models that show some of the questions we must answer to be able to

describe an actual integration.

First of all, we could decide on what integration means, or what we are trying to achieve.

Here is one attempt at a definition:

Integration: Two systems are integrated if an event in one system (system A) thatmight potentially affect decisions being made in another system (system B) is alwaysreflected in system B in system real time.(McComb 2003:225)

What the quote states is that, if two systems have overlaps in terms of what objects or

entities they consume or manipulate, integration means that the manipulation of the

entity is visible wherever the entity is used, or in other words the manipulation is repli-

cated between the systems. McComb uses the term decision, which to me suggests hu-

man involvement, which, just to be clear, is of course not necessarily the case. He also

seems to think that the replication has to happen real-time, which suggests that non-real-

time integrations are lesser integrations. So time is a factor.

On systems and applications: when I say we want to integrate two or more systems, we

have to have a notion of what a system is in the first place. In this context I use the term

system synonymously with an application, with the added dimension of the applications

surroundings, where decisions have been made about frameworks, operating systems,

programming languages, lower level infrastructure etc., but both terms have become

fuzzier than they were earlier. This is certainly the situation in the specific case we will be

looking at in a little while. So when considering system or application integration, it is

essential to bear in mind the context and surroundings of the application.

My understanding of truly integrated systems is a situation where all the individual

systems act as one. What we have to be clear about is the importance of choosing our

scope; large enterprise systems are architecturally made of smaller parts, and these

smaller parts could again be divided into subparts. If we choose the scope of the whole

enterprise, the whole system might not be very integrated, but zooming in on specific

parts may reveal very tight integration. This seems obvious, but is nevertheless impor-

tant. I prefer an understanding that says that systems are integrated when the border

between the parts and the whole becomes blurry. This is very debatable, but I found it to

be the least poor description. The reason why it is debatable is that a cardinal point in


25/100


SOA is to split up systems in well defined pieces, but let them work together seamlessly.

So it is a question of what technological context you have.

There are many problems that a strict definition cannot handle. For example, an applica-

tion could have multiple presentation layers exposing different parts of the business

logic, or, put differently, an application could serve very different types of users, that

perform actions on the application that have little or no influence on each other. The

functionality that lies in application layer might be so generic that it does not determine

what it is used for. This we would normally consider two separate applications since

there is no causal relationship between them, determining decisions being made in

another system. On the other hand, they are clearly using the same physical application

layer code to perform tasks, but would under this definition not qualify as integrated. A

clear-cut and absolute definition might not be within reach, but I think we have the basic

concept in place and we will continuously be adding to our understanding of the term.

Interoperability has also been understood in many ways. The way I will use the term is as

the result of integration; integrated systems result in interoperability between them. This

understanding is not the most technically elaborate, but is sufficient for our purposes.

3.1. Why is integration important?

Now we will review the broader context integration has to be seen in. What is this inte-

gration supposed to achieve in the first place? What are the business needs that drive the

actual low level needs? The definition of what is needed is of course dependent on

whom you ask. The web services technology, for example, which has been widely mar-keted as an integration technology, has largely been brought forward by industry. This

obviously leads to a somewhat biased view of what we need. How the standards have

come to look like they do today would make a very interesting discourse analysis. How-

ever there does seem to be a surprising consensus on the need for effective integration

technology, so let us look at those perspectives. This is really a continuation of the argu-

ments for IT architecture. IT architecture means a more holistic view, and as a conse-

quence of a holistic view we need to link the pieces. Otherwise the macro perspective

would not be new.

Porter uses the concept of linkages to describe the interdependencies in and between

organizations, and how it can be the source of competitive advantage:

Linkages exist when the way in which one activity is performed affects the cost of ef-fectiveness of other activities. Linkages often create trade-offs in performing differentactivities that should be optimized.[] Careful management of linkages is often apowerful source of competitive advantage because of the difficulty rivals have in per-ceiving them and in resolving trade-offs across organizational lines. [] Linkages notonly connect value activities inside a company but also create interdependencies be-tween its value chain and those of its suppliers and channels. A company can createcompetitive advantage by optimizing or coordinating these links to the out-

side.(Porter, Millar 1985)


26/100


A technological embodiment of linkages is integrations and can thus be the basis for

improving the organizations performance. But what does this mean for the strategic

process? For one, it becomes more important than ever to integrate the general strategic

process with IT strategy and enterprise architecture. A few of the potential impacts of

successfully leveraging integration technology might include (Marks, Werrell 2003: 89):

Identification of target markets. The scope of products and services could shift,

either as a consequence of the organizations own strategy-change or in response

to competitions initiatives.

Corporate Performance Management (CPM). As systems become more

integrated and exchanging information becomes easier, cheaper and less error

prone, we will see a move to closer-to real time reporting. This will enable the

management to keep abreast with up-to-the-minute metrics and act accordingly.

Value chain visibility. Web services will enable the organization to see straight

down the supply chain, and in some cases also up the demand chain. Information

form disparate sources will be aggregated to create more knowledge and insight

of the available information. This will happen first internally in the organization

and increasingly between them.

Automation of business processes. Business process definition management will

become cheaper and more viable across organizational boundaries.

Agility. Organizations will feel less constrained by the IT infrastructure as

flexibility increases. Errors due to unforeseen consequences of changes to systems

will be less likely, as the infrastructure becomes more service oriented.

Organization structure. As the IT infrastructure becomes more open and less of a

constraint, it will define the organizational structure less and less. This will mean

that we will see more fuzzy hierarchies and more fuzzy organisational borders.

You might think that this sounds very business minded, and not very relevant for the

public sector, but if we consider for example the way public sector organizations are now

called public firms and have to submit financial reports much in the same way private

firms do, we will realize that there has been a shift in the way public sector organizations

are thought of. Obviously, there are important differences between public and privateorganizations, for example the level of accountability we could expect. This means that

some considerations may weigh heavier than others, but there are no fundamental differ-

ences that drastically alter our IT architectural goals.

The technological infrastructure to achieve these ambitions in an efficient way has not

been put firmly in place, so there has been a technological vacuum with regard to fulfill-

ing the identified business need, which is also a need for more dimensions to compete in.

If for example the technological capability of integrating seamlessly with partners is

achieved, the ability to manage your business network will therefore be an even moreimportant competency in the future, since technology lock-ins will have relatively less


27/100


force. The future might give us the opportunity to blur the difference between a tradi-

tional value chain internally in an organization and the external supply and demand

chains. This means that one piece of the value chain can be put more easily in an inde-

pendent organization, but still keep the close information-based ties that are so impor-

tant. This relates to the core competency trend some time ago and, more recently, themove towards on-demand thinking, which many corporations are embracing. This is, of

course, one of the main strategic directions IBM is pursuing. The reason for this is that

organizations need to lower their fixed costs to a minimum. At a time where the thoughts

of Ulrich Beck are more relevant than ever, it has become more attractive to pay someone

else to take some of your risk, or share it with others. Marginal costs become relatively

more attractive, even if you do pay a little more. Again, the technology to do this is some-

thing we need. But let us move slightly away from the strategic to the operational. As

always IBM (Nix 2004) is ready to give advice on what we need:

We want and need:

to integrate systems regardless of their implementation

to move from monolithic, custom-coded apps to choreographed, scripted

components.

agility and flexibility to reconfigure business functions to try new process

models.

to move from tightly coupled systems to loosely coupled ones to deal with

inevitable change.

a well-understood programming model for connecting businesses via the

Internet.

This will mean that we might see a fragmentation and integration/collaboration sce-

nario, where the lower transaction cost will mean that it would be more of a viable solu-

tion to outsource it. This will give rise to new markets of specialized functions, tradition-

ally thought of as strictly in-house.

Transaction cost theory asserts that the price of a product is comprised of three ele-ments: production costs, co-ordination costs and profit margin. Co-ordination costsinclude the transaction costs of all the information processing necessary to co-ordinatethe application of the resources employed in primary activities. (Scott, Comer1999:135)

As the price of coordination costs come down, transaction costs as a whole come down,

and the market will be more plastic.

3.2. Technical integration

The overall issue we are trying to grasp is how to make sense of applications that have to

interact in some way. Earlier applications were developed with a stove-pipe mentality,


28/100


meaning that each application was thought of as an independent silo, which was not

supposed to communicate or interact with other applications. This is changing. Now we

want applications to come together as a larger whole and become coherent. What were

once multiple separate applications should now become one distributed application.

Distributed means that we may view the individual applications as parts of a greaterapplication, and so on one level it is merely a concept; we can choose to look at a group of

applications as one larger distributed application if they are integrated. But there is also a

technological level that must be considered. We cannot simply choose to view multiple

applications as one whole, if the technological infrastructure is not in place. Integrating

systems can have many purposes, be it providing a web interface to your old mainframe

applications, consolidating multiple legacy systems into one and adding additional ap-

plication logic, or probably one of the most common, trying to open up your systems to

be able to interact more freely with other systems in other organizations.

If you know exactly what you want, and you will need the same thing for a long time,

and the marketplace does not change, then you are fine. But this is simply not the case.

Examples of types of things organizations need to be able to do include:

On the developer level: Use functionality from different physical and logical

applications (thus breaking up our understanding of what an application is and

its boundaries)

On the business level: Aggregate output from multiple systems to achieve a more

transparent view of the organization. A common use being business intelligenceor to facilitate cross-application business processes.

We have been able to use functionality from other applications before, but because it was

proprietary technology and no one was powerful enough to dictate the whole market,

these technologies have been unsuccessful. There have been initiatives that can do what

we need, e.g. CORBA or Microsofts COM, but due partly to the lack of widespread

adoption these technologies have not been able to deliver on the need for distributed

computing in any real way.

The reasons for this capability are many, but let me just provide one example. In todaysbusiness environment, businesses are bought and sold at an enormous rate. The costs

involved in mergers and acquisitions are huge. Most of the difficulties in M&As are usu-

ally attributed to organizational problems, but considerable resources go to integration of

systems. Having a technology that could facilitate this process and help to design systems

that allow for rapid take-over, would increase the market value of a firm and the money

spent on the buyer side. An attractive prospect. M&As make me think of an upcoming re-

structuring of the Danish municipalities, so it is clear that M&A thinking is very relevant

in the public sector as well.


29/100


In the following sections I will present the most fundamental building blocks and con-

cepts for system and application integration. We will need this terminology when we

have to talk about the actual issue at hand in our case, the questions surrounding the

integration between Enterprise Content Management systems and systems from KMD. I

will not draw on all concepts in later chapters, but the following should also give animpression of the field in a broader sense and what types of problems are dealt with.

For the purpose of this thesis, I have been forced to caricature things a little, and simplify

certain things. Instead of giving an over-dose of technical details, I have tried to keep

things as concise as possible, and only present what we need in order to understand the

issues in systems integration. It is probably easiest to start out with the good old 3-tier

understanding of an application. As we know, a generic application consists of a data

layer, an application layer where program logic resides, and a presentation layer where

the interface is built. An example of a simplification is the presumption of a three-layer

architecture in the following integration models, which is not at all a given. Many appli-

cations have additional levels, some applications have layers that are mixed together, and

some applications are missing one layer, e.g. a user interface if the application is only

used for machine-to-machine situations, or perhaps has no database at all if the applica-

tion only manipulates data from another application.

3.3. Integration models

This is what its all about: integration. But what is integration exactly? What types of

integration exist, and how do they differ? In the following we will take a look at integra-tion models which indicate different entry points to applications and are thus different

ways of integrating two applications. Following the standard three-tier architecture, these

are the three basic integration models. You may access an application either by way of the

presentation layer, the functional (application) layer or directly to the database at the data

layer. The different types of access are appropriate in different situations depending on

goals and constraints.

3.3.1. Presentation integration model

Sometimes the only access you have to an application is via the presentation layer. Not allapplications have a presentation layer in a graphical sense, but most do.

This form of integration is useful only when the integration can be accomplished us-ing the user interface or presentations level of the legacy applications. Integration ofthis type is typically oriented to textual user interfaces such as IBM 3270 or VT 100interfaces. (Ruh 2001:22)

Figure 7 demonstrates an integration where two presentation layers are aggregated into a

third. This is slightly simplified, as you would obviously need to have some application

to control the aggregation and produce the third presentation, but the figure shows the

goal of an integration. A great advantage of this integration model in our context is thatyou do not need to have control over the applications inner workings. This means that


30/100


you do not have to have access to the lower level application or data layer to use this

model.

Figure 7: Presentation integration model

The down side is off course that you are limited to the functionality that is given in the

original presentation. This means that you cannot create new functions or logic without

them having to go via one or more presentation layer screens. For example if you want to

create a new function called CreateCaseAndSendToOrg(orgid), and this process would

ordinarily take the user to multiple screens in a certain order, some special software

called middleware would have to do exactly the same as the user, and expose that proc-

ess as a function that could be invoked by another application, thus simulating the crea-

tion of a new function. Simulating users also creates performance issues as you add an

additional layer to the integration, and the presentation layer is probably the slowest

with the most overhead, although if it is a text-based application that is in question, this

is less of an issue.

3.3.2. Functional integration model

In functional integration we use the existing business logic in the underlying applications

to access and manipulate data. Figure 8 shows how middleware can aggregate the two

application layers, perhaps transform them and publish them to the third, new, applica-

tion on top, essentially creating a new application. This ensures consistency (to the extent

that the underlying application business logic ensures consistency) in the database and

can help to prevent problems with relational integrity, if securing relational integrity has

been put in the business logic layer. Functional integration is by far the most robust

method and is the basis of the bulk of integration patterns.


31/100


Figure 8: Functional integration model

Functional integration can be grouped into three approaches that reflect the goal of the

integration:

Data consistency is quite self-explanatory, the point being to maintain

consistency across multiple applications that have overlaps in data, for example,

if name and address information is in multiple applications, there is a need to

push an update out to all the relevant applications. This approach promotes loose

couplings where the (especially the receiving) applications have little or no

awareness of the other applications. The sending application uses a fire-and-

forget strategy where there might not even be a response from the receiver: a

typical asynchronous approach.

Multistep process involves an orchestrated series of interactions between

systems. There is often a need for multiple applications to support a businessprocess, where the individual applications have different roles, but the process

needs to follow a specific sequence and perhaps a specific schedule. The role of

middleware is to couple these applications and perhaps use a workflow engine to

control the actual process steps. A multistep process usually promotes tight

couplings among applications, since all applications are typically needed for the

process as a whole. If one application is down, the whole chain is down. Since the

individual communications between the applications and the middleware are

part of a larger process, there is a greater need for ensuring that the

communication has gone as planned. There will therefore be more two-way

communication, which can be synchronous or asynchronous.


32/100


Component integration is about modularizing applications and unifying your

application portfolio into one coherent whole. This plug-and-play idea could be

thought of as Legos that can be used as clusters of functionality that can be

interchanged easily with other blocks. Component integration is more strategic as

it requires considerable effort to implement. It requires an enterprise-wide plan

and coordination of efforts, and detailed knowledge of the existing applicationsis needed. It encourages having one consistent semantic model of data and

functions across all applications, which is a tall order in many real world

scenarios. Component integration favours tight coupling.

3.3.3. Data integ

Brian Kane Thesis EAI FINAL Public Version v3

Documents

Transcript of Brian Kane Thesis EAI FINAL Public Version v3