Enterprise Architecture - inkl. rammerværker - i teori …W3-projekt – Enterprise Architecture,...

Vibeke Eriksen Charlotte Cleemann Pedersen

Forår 2004

Enterprise Architectureinkl. rammeværker – i teori og praksis

IT-Universitetet Vejleder: John Gøtze

W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004

Indholdfortegnelse

Projektets deltagere ................................................................................................................... 4

1. Indledning ............................................................................................................................... 5

2. Introduktion til arkitekturrammeværker ........................................................................... 6

2.1. Enterprise arkitektur.............................................................................................................. 6

3. Zachman ................................................................................................................................. 8

3.1. Zachmans rammeværk .......................................................................................................... 8

3.1.1. Regler for rammeværket .................................................................................................. 11

3.1.2. Brug af Zachmans rammeværk – styrker og svagheder................................................... 12

3.2. Afrunding............................................................................................................................ 14

4. Herzum – EA og Rammeværker ........................................................................................ 15

4.1. EA-modenhedsfaser............................................................................................................ 17

4.2. EA rammeværktøjer............................................................................................................ 18

4.2.1. EA-første generationsrammeværktøj - Zachman............................................................. 19

4.2.2. EA-anden generationsrammeværktøj – COSM ............................................................... 20

4.3. EA-strategi .......................................................................................................................... 22

4.4. Afrunding............................................................................................................................ 23

5. Analyse af VA ....................................................................................................................... 25

5.1. Historik – motivation for etableringen af en EA ................................................................ 25

5.2. Introduktion til VAs EA implementeringsplan................................................................... 27

5.3. Udvikling af arkitektoniske principper ............................................................................... 29

5.4. Fremgangsmåde i forbindelse med udviklingen af One-VAs EA i 2003 ........................... 30

5.5. VAs brug af Zachman rammeværket.................................................................................. 32

5.6. One-VAs EA som en ”driver” i forbindelse med investeringer ......................................... 35

5.7. EA-udviklingsindsats.......................................................................................................... 38

5.7.1. Hvad har de nået fra 2002 til 2003 – eksempler på de væsentligste resultater ................ 38

5.7.2. Planer for år 2003 – eksempler på de væsentligste resultater.......................................... 38

2


5.8. VA i forhold til GAO.......................................................................................................... 39

5.9. Afrunding – generel vurdering............................................................................................ 40

6. Analyse af H:S ...................................................................................................................... 43

6.1. IT-strategien........................................................................................................................ 43

6.2. H:S og Enterprise Architecture........................................................................................... 46

6.3. H:S i praksis........................................................................................................................ 47

6.4. Afrunding - H:S og VA ...................................................................................................... 50

7. Perspektivering .................................................................................................................... 53

8. Konklusion............................................................................................................................ 56

9. Litteraturliste ....................................................................................................................... 58

3


Projektets deltagere

Vibeke Eriksen er Erhvervssproglig Bachelor fra Handelshøjskolen i Århus, 2000. Hun har

arbejdet som projektkoordinator hos A.P. Møller i 2 ½ år, inden hun startede på IT

Universitetets E-businesslinje i februar 2003. På 1. semester har hun fulgt kurserne

”Grundkursus i Netværk- og Operativsystemer”; ”IT- og Internetjura” samt ”Strategiske og

Taktiske Værktøjer til E-business”. På 2. semester har hun fulgt kurserne ”IT-Sikkerhed”;

”Grundlæggende Programmering” samt ”Logistik og Supply Chain Management”. På 3.

semester har hun fulgt kurserne ”Enterprise Architecture” og ”Databasesystemer” på ITU samt

”Consumer-Driven Value Networks” på Handelshøjskolen i København. I løbet af de tre

semestre har hun skrevet projekterne ”EasySwap.biz – en forretningsplan for en dansk/svensk

boligbytteportal”; ”Et client/server projekt – udviklet udfra et objektorienteret perspektiv” samt

”Enterprise Architecture inkl. rammeværker – i teori og praksis”, der hver især tæller for et fag.

Charlotte Cleemann Pedersen er HA(jur)’er fra Syddansk Universitet i Odense. I februar

2003 påbegyndte hun sine studier på IT Universitetets E-businesslinje. På 1. semester har hun

fulgt kurserne ”Grundkursus i Netværk- og Operativsystemer”; ”IT- og Internetjura” samt

”Strategiske og Taktiske Værktøjer til E-business”. På 2. semester har hun fulgt kurserne ”IT-

Sikkerhed”; ”Grundlæggende Programmering” samt ”Logistik og Supply Chain Management”.

På 3. semester har hun fulgt kurserne ”Enterprise Architecture” og ”Databasesystemer” på ITU

samt ”Consumer-Driven Value Networks” på Handelshøjskolen i København. I løbet af de tre

semestre har hun skrevet projekterne ”EasySwap.biz – en forretningsplan for en dansk/svensk

boligbytteportal”; ”Et client/server projekt – udviklet udfra et objektorienteret perspektiv” samt

”Enterprise Architecture inkl. rammeværker – i teori og praksis”, der hver især tæller for et fag.

4


1. Indledning Enterprise Architecture (EA) er begyndt at gøre sit indtog i både private og offentlige

virksomheder. Det sker på baggrund af organisationers erkendelse af, at en styret IT integreret

på tværs af organisationen som en understøttende faktor for den generelle forretning kan

bidrage positivt til virksomheden. I dagens utrolig hurtigt forandrende verden, er en agil IT-

portefølje, der hurtigt og effektivt vil være i stand til at håndtere forandringer, en

nødvendighed, for at organisationer kan klare sig i den hårde konkurrence virksomhederne

imellem.

EA-rammeværker er en støtte i organisationers udarbejdelse af en EA i deres forsøg på at styre

til tider kaotiske IT-porteføljer. Rammeværker kan hjælpe organisationen med at udpege,

hvilke perspektiver og aspekter de skal have belyst i deres kortlægning af deres nuværende

systemer og funktioner samt ved deres ønskede mål. Dette vil så danne grundlaget for en

effektiv transformation til de nye mål på basis af strategisk udvalgte områder.

I nærværende projekt vil vi se nærmere på EA, herunder rammeværker. I teorien vil fokus især

være på Zachmans meget berømte rammeværk, hvor Herzums syn på EA inddrages for dermed

at give et andet perspektiv på EA-emnet. Teorien illustreres med to praktiske cases. Først ser vi

på myndigheden Veteran Affairs (VA) i USA, der er et skoleeksempel på udførelsen af en EA-

proces. Fokus i denne case vil hovedsageligt være på, hvordan VA håndterer deres EA i dag i

deres forsøg på at optimere deres forretningsprocesser, hvor kunderne er i centrum. Herefter

anvender vi H:S (Hospitalernes Sygehusfællesskab) som et dansk modstykke til VA. Med H:S

tager vi udgangspunkt i deres IT-strategi og ser lidt på, hvor de er i dag i relation til EA. En

sammenligning af VA og H:S vil blandt andet bringe os ind på kulturelle forskelligheder samt

de to organisationers meget forskellige modenhedsniveauer i forhold til EA.

Sluttelig afrundes projektet med en kort perspektivering. Her ser vi på, hvad især H:S skal være

opmærksom på i forbindelse med deres EA-proces samt de udfordringer, der ligger i

fremtidens EA.

Vi har i udarbejdelsen af projektet holdt interviews, som har været utrolig givende i forhold til

de benyttede bøger, artikler og hjemmesider. Disse interviews har uden tvivl være en stor hjælp

til at belyse de berørte emner fra en mere praktisk vinkel.

5


2. Introduktion til arkitekturrammeværker Inden en organisation påbegynder arbejdet med arkitekturrammeværker, er det nødvendigt, at

de er fuldt ud klar over, hvad et rammeværk er og kan bruges til. Arkitekturrammeværker kan

være en stor hjælp i en organisations arbejde med at få defineret og dokumenteret1IT-

arkitekturer, der skal hjælpe organisationer med at få deres IT-porteføljer til at understøtte den

generelle forretning. Rammeværket giver i sig selv ikke nødvendigvis løsningen til, hvordan

arkitekturerne anvendes, men fungerer i stedet som en løftestang til at overskue emner og

problemer. Desuden medvirker de definerede arkitekturer også til, at organisationen har en

fælles referenceramme, der gør, at folk taler ”samme sprog”, når de blandt andet ønsker at få

løst et problem, der relaterer sig til indholdet i rammeværket. En organisation behøver ikke

starte med at udfylde et stort og omfangsrigt rammeværk, men kan sagtens starte i det små, og

dermed bliver arbejdet også mere overskueligt og realistisk.

Der findes en lang række forskellige rammeværker, og de har det til fælles, at de ofte bruger

enslydende arkitektoniske definitioner. Til gengæld kan de variere meget i scope, fokus og

formål. Dette er yderst hensigtsmæssigt, da de skal støtte en lang række forskellige områder

f.eks.”system arkitektur” og/eller ”software arkitektur”. Når en organisation skal vælge et

rammeværk, bør de blandt andet tage hensyn til både deres interessenter og domæne. Her er det

vigtigt at huske, at rammeværket skal formidle de informationer videre, som er relevante for de

individuelle interessenter.

2.1. Enterprise arkitektur

EA er ifølge The Federal CIO Council, USA ”strategiske aktiver bestående af de

informationer, der definerer forretningen, de informationer, der er nødvendige for at drive

forretningen, de teknologier, der er nødvendige for at supportere forretningsoperationer og de

transformationsprocesser, der er nødvendige for at implementere nye teknologier i relation til

at håndtere ændrede forretningsbehov”2. EA indeholder således de principper, metoder,

guidelines m.v., der er nødvendige, for at en virksomhed kan styre deres IT-portefølje således,

at denne sammenholdes med organisationens overordnede vision.

1 ”IT-arkitektur beskriver den grundlæggende organisering af et eller flere IT-systemer, herunder principper for systemernes design og udvikling og for deres indbyrdes sammenhæng” (Hvidbogens definition af IT-arkitektur) 2 http://cio.ost.dot.gov/architecture/ (frit oversat til dansk)

6


Et rammeværk benyttes i organisationen med det for øje at få defineret enterprise arkitekturen,

der har det formål at få klarlagt den nuværende forretning inklusiv dennes systemer (”as is”).

Derudover skal organisationen have defineret den situation, de ønsker at nå frem til på et mere

eller mindre detaljeret niveau (”to be”). Dette vil så være en hjælp i forbindelse med at få

ændret gamle systemer, hvor det er relevant, så de svarer til de nye mål samtidig med, at

arkitekturerne også vil fungere som en styringsmodel, når organisationen anskaffer sig nye

systemer. På denne måde kan en virksomhed sikre sig, at dens IT-portfølje understøtter dens

overordnede forretningsvision. Resultatet af dette er også, at organisationen bedre, hurtigere og

mere effektivt kan håndtere de forandringer, den uundgåelig må forholde sig til i forhold til

omverdenen.

Der er som ovenfor nævnt forskellige rammeværker, en virksomhed kan benytte sig af alt

afhængig af organisationens ønsker og mål. Zachmans rammeværk, der indeholder en række

principper til at opbygge en EA, er formentlig det mest kendte, men der findes også andre

rammeværker, der tilbyder en anden metode. Et eksempel på dette er TOGAF, der har stor

fokus på de tekniske aspekter i modsætning til Zachman, der i højere grad fokuserer på

helheden. Da Zachmans rammeværk er det mest anerkendte, vil det være dette rammeværk, der

bliver beskrevet mere dybdegående i nærværende projekt samtidig med, at brugen af

rammeværket gennemgående vil være i fokus i projektet. I afsnittet med Herzum, vil hans

COSM rammeværk dog kort blive beskrevet i relation til hans generelle vurdering af

rammeværker.

7


3. Zachman En organisations informationssystemer er ofte en kompleks størrelse. De lader sig vanskeligt

beskrive, da forskellige grupper af medarbejdere har deres egen måde at beskrive og forholde

sig til systemerne på. Det kan derfor være svært for en organisation at få et overblik over,

hvordan systemerne fungerer, hvilke data de indeholder, hvilke investeringer der er foretaget i

IT m.v. Denne kompleksitet er en af årsagerne til, at John Zachman i 1980’erne udviklede et

rammeværk. Rammeværket skulle hjælpe organisationerne med at overskue deres

informationssystemer. Derudover ville et sådant rammeværk også tilskynde til, at der kom

langt mere sammenhæng mellem IT og forretningen. Zachman var inspireret af flyindustrien,

som er karakteriseret ved, at den har fuld kontrol over hver enkelt del på de specifikke fly, lige

fra hvem der udvikler og vedligeholder de enkelte dele, til de fly, der indeholder de specifikke

dele. Zachmans teori var, at denne kontrol måtte kunne overføres til organisationers styring af

IT. I 1987 udgave han ”A framework for information systems architecture”, og senere i 1992

sammen med Sowa udgav han opfølgeren ”Extending and formalizing the framework for

information systems architecture”. Artiklerne er begge en beskrivelse af hans forslag til et

rammeværk, og de har således været med til at præge EA verden over.

3.1. Zachmans rammeværk

Et rammeværk er et sæt af antagelser, koncepter, værdier og handlingsmønstre, der tilsammen

udgør en måde at se virkeligheden på. Zachmans rammeværk er et klassifikationsskema for

artefakter. Disse artefakter beskriver de forskellige designtyper, der bruges i forbindelse med at

udvikle og implementere software. Rammeværket er metode og procesuafhængigt, hvilket

betyder, at rammeværket ikke definerer de leverancer, en organisation skal komme frem til,

eller hvordan de kommer frem til dem. Rammeværket henvender sig til alle organisationer

uafhængigt af antallet af systemer.

Formålet med Zachmans rammeværk er at give organisationer mulighed for, at de kan danne

sig et overblik over deres systemer ud fra flere forskellige perspektiver. Derudover giver

rammeværket også mulighed for, at organisationen kan overskue, hvordan disse perspektiver er

relateret til hinanden. Rammeværket gør således klart, at et produkt har flere involverede

parter. Det er ikke kun IT-folk eller forretningsfolk, der har et forhold til, hvordan et systems

arkitektur bør se ud, men derimod er det vigtigt, at alle perspektiver inddrages for at opnå den

bedst mulige løsning for organisationen.

8


I sin første artikel ”A framework for information systems architecture” opstiller Zachman en

matrix bestående af seks rækker og tre koloner. I hans anden artikel ”Extending and

formalizing the framework for information systems architecture” udvider Zachman

rammeværket med tre ekstra koloner (se bilag 1). I den første artikel sammenligner han

udfyldningen af hans rammeværk med det at planlægge og bygge et nyt hus. Sammenligningen

giver et godt billede af, at et gennemarbejdet projekt skal igennem flere perspektiver, f.eks.

husejeren, arkitekten og bygherren, der hver har deres eget udgangspunkt og referenceramme

for projektet samtidig med, at de dog er begrænset af det forrige perspektivs ideer og

beskrivelser. Zachman ender således op med matrixen, der er nævnt ovenfor, der blandt andet

indeholder perspektiverne ”owner’s view”, ”designer’s view” og ”builder’s view”, der hver

især er vigtige for at nå til en helhed, f.eks. et færdigbygget hus.

Rækkerne i matrixen repræsenterer de involverede interessenters perspektiver. Karakteristisk

for dem er, at de omhandler de forskellige perspektiver, de involverede interessenter har på et

specifikt projekt. Således bliver perspektiverne afhængige af tidligere definerede perspektiver i

matrixen, hvilket betyder et større detaljeringsniveau jo længere ned i rammeværkets

perspektiver, en organisation kommer. Kolonnerne repræsenterer derimod aspekter, hvilket

svarer til forskellige områder, som et projekt skal forholde sig til. Samlet set består

rammeværket af 30 celler, der hver især er resultatet af et aspekt og et perspektiv.

Perspektiverne

• Scope (Planner’s view) – Definition på organisationens retning og mål, samt en

afgrænsning af arkitekturprojektet.

• Business Model (Owner’s view) – Definerer organisationen ud fra et

forretningssynspunkt, inklusiv forretningsstrukturer, forretningsprocesser og

forretningsorganisationen.

• System Model (Designer’s view) – Detaljeret uddybning af forretningsmodellen

(”Business Model”), hvor der tages højde for, hvad der teknisk og fysisk er muligt.

• Technology Model (Builder’s view) – Definition på, hvordan teknologien kan opfylde

de behov, der er defineret i de tidligere perspektiver.

• Detailed Representation (Subcontractor’s view) – Detaljeret subdesign, f.eks.

implementeringssprog og databaselagerplads.

9


• Functioning Enterprise – Det faktiske system.

Aspekter

• Data (What) – Hvilke vigtige entiteter, objekter og komponenter har organisationen, og

hvordan hænger de sammen.

• Funktion (How) – Hvordan virker organisationens forskellig processer.

• Network (Where) – Hvor er placeringen af organisationens aktiviteter (geografisk).

• People (Who) – Hvem er involveret i organisationen.

• Time (When) – Hvornår udføres aktiviteterne med henblik på, hvad tid betyder i

forhold til planlægning for organisationen.

• Motivation (Why) – Hvorfor udføres et projekt. Dette ses i relation til de mål, strategier

og begrænsninger organisationen har sat i forhold til det specifikke projekt.

Cellerne I cellerne beskriver Zachman de enkelte relationer mellem aspekter og perspektiver. Zachmans

forklaringer på cellernes funktion er dels beskrevet gennem grafiske beskrivelser og dels med

korte sætninger eller blot stikord. Han har på forhånd valgt ikke at definere, hvad cellerne

indeholder i detaljer, men i stedet lade det være op til den organisation, der ønsker at benytte

rammeværket. Han anser de grafiske beskrivelser for at være langt mere universelle end

beskrivelser med ord og langt lettere at forstå end matematisk logiske beskrivelser.

Eksempelvis viser cellen Network (aspekt) og Scope (perspektiv) et verdenskort, hvilket giver

organisationen en ide om, at denne celle har fokus på geografisk placering af forretningen.

Anvendelsen af grafiske beskrivelser er således med til at gøre Zachmans rammeværk endnu

mere procesuafhængigt, idet det er op til organisationen at fortolke de grafiske symboler.

Målet med cellerne i rammeværket er, at deres indhold er selvstændigt. På denne måde

fungerer hver enkelt celle uafhængig af de andre. Verden forandres med tiden, hvorfor

organisationerne er nødt til at være forberedte på hurtigt at kunne håndtere sådanne

forandringer. Det kan give problemer, hvis artefakter i en organisations IT-system eller hele

IT-portefølje er for afhængige af hinanden. Det betyder, at selvom en virksomheds systemer er

integreret skal de kunne ændre på èt system eller dele af et system, uden det påvirker alle de

andre, hvis dette ikke er ønskeligt. Det er en problemstilling, der har givet store udfordringer

verden over, og Zachman har derfor med sit rammeværk forsøgt at skabe en stabil struktur, der

bygger på selvstændige enheder.

10


Ofte vil organisationer have behov for at kombinere cellernes indhold. I en sådan situation er

det hensigten med rammeværket, at en virksomhed udvælger de celler med det indhold, som de

ønsker at kombinere. Det kan lade sig gøre, fordi rammeværket er skabt som en reol. Man kan

tage den bog ud fra reolen, man skal bruge, uden at det påvirker de andre bøger på hylderne.

Det er derfor et krav, at bindingerne mellem cellerne er så svage, at ændringer i de enkelte

celler kan gennemføres, uden det påvirker resten af cellerne. Yderligere er det også et krav, at

når en organisation kombinerer informationer fra forskellige celler kan dette kun lade sige gøre

vertikalt eller horisontalt og aldrig på tværs i rammeværket. Grunden til dette er, at artefakter

kun kan bindes sammen, hvis de enten har samme aspekt eller samme perspektiv.

Det er dog desværre kun i den ideelle verden, at en virksomhed kan plotte alle sine

informationer ind i netop én celle uden at stå tilbage med informationer, der ikke passer præcist

ind i en celle. Artefakter, der passer præcis ind i en celle, kaldes primitive artefakter3, mens de,

der falder mellem nogle celler, kaldes for sammensatte (composite) artefakter4. En måde at

undgå sammensatte artefakter på er ved at normalisere5, så de kun tilhører én celle.

3.1.1. Regler for rammeværket

I sin anden artikel opstiller Zachman syv såkaldte regler for rammeværket. I stedet for at

benævne dem for regler, ville det måske være mere korrekt at karakterisere dem som

naturregler, som rammeværket eksisterer under. De giver brugeren af rammeværket et bedre

overblik, der hjælper til at forstå anvendelsen af rammeværket.

1. Alle kolonner er ligeværdige, der er ingen prioritering af dem, der implicerer

ensidighed.

2. Hver kolonne har en simpel basismodel, der repræsenterer en abstraktion af den

virkelige verden. Modellen er en generisk metamodel.

3. Hver kolonnes basismodel skal være unik. Selvom kolonnerne viser et billede af den

samme verden, er de alligevel selvstændige og unikke.

3 Primitiv model: Det laveste beskrivelsesniveau af en artefakt. En primitiv er skæringslinien af et enkelt perspektiv med et enkelt aspekt. 4 Sammensat model: En beskrivelse af en artefakt, der ikke er en primitiv. En sammensat artefakt, er en artefakt, der inkluderer beskrivelser fra mere end en celle. 5 Normaliserede artefakter er kendetegnet ved kun at tilhører en celle, og er således ikke sammensat af flere artefakter fra flere celler. Det er det laveste dataniveau (primitiver).

11


4. Hver række repræsenterer et tydeligt og unikt perspektiv, på baggrund af perspektivets

”ejer” og de begrænsninger, denne ”ejer” er bundet af.

5. Hver celle er unik, da både kolonnerne og rækkerne er unikke.

6. Summen af alle cellerne i en række giver et komplet billede af virkeligheden ud fra

perspektivet i den aktuelle række. Derfor er en celle relateret til alle andre celler i

samme række.

7. Logikken i rammeværket kan bruges i enhver situation.

3.1.2. Brug af Zachmans rammeværk – styrker og svagheder

Rammeværket skal være en hjælp til en organisation i relation til at skabe sig et overblik over

dens IT-systemer. Rammeværket bør indeholder både organisationens ”as is” og ”to be”

situationer, der efter bearbejdning kan implementeres i en styringsmodel, der gør, at en

virksomhed lettere kan håndtere forandring og skabe udvikling. Dette vil således også betyde,

at organisationen kan blive mere konkurrencedygtig.

Rammeværket er en metamodel, der indeholder en kort beskrivelse af, hvilken type af

informationer, der skal placeres i de enkelte celler. Dog er det vigtigt at gøre sig klar, at

rammeværket ikke definerer, hvordan en organisation skal komme frem til et resultat på

baggrund af udpegede problemfyldte områder. Det er en af rammeværkets styrker, da det

betyder, at en organisation i høj grad kan bruge rammeværket på den måde, der passer bedst til

dens behov. Omvendt kan det være en svaghed, at der ikke findes en detaljeret manual, der

beskriver, hvorledes en organisation bør gribe arbejdet med rammeværket an, da det kan virke

meget uoverskueligt samtidig med, at omfanget af rammeværket med 30 celler desuden kan

virke utrolig komplekst for mange organisationer. Til hver celle hører også et minimum antal

artefakter, hvilket sammenlagt kræver store mængder dokumentation og store krav om

håndtering af komplekse data i en database. Disse forhold vil formentlig umiddelbart afskære

en del virksomheder fra at anvende rammeværket, især hvis de ikke formår at se de resultater,

et sådant rammeværk kan bibringe organisationen i relation til at få struktur på deres IT-

systemer.

Udfyldningen af hele rammeværket giver en organisation en detaljeret oversigt over dennes IT-

systemer set fra alle hjørner af en organisation. Det er dog ikke et krav, at hele rammeværket

anvendes, da en organisation kan vælge at anvende ”slivers”. ”Slivers” betyder, at

12


virksomheden tager et udsnit af rammeværket langs kanterne i de enkelte celler på baggrund af

projektets scope og det detaljeringsniveau, en organisation ønsker at anvende.

Figur 1 - Illustration af ”slivers”.

Kilde: www.zifa.com

Benyttes ”slivers” skal projektet således ikke fokusere på alle organisationens informationer,

men i stedet på de informationer, der er relevante for det specifikke projekt. Dog skal det ikke

glemmes, at resten af rammeværket også eksisterer, hvilket betyder, at der skal være tale om et

bevidst fravalg, hvis dele udelukkes. Det kan vise sig at være en utrolig krævende proces, at

overskue hele rammeværket på en gang. Forsøger et projekt således at dække hele

rammeværket, bliver det en meget langsigtet proces, der f.eks. kan resultere i, at projektet ikke

matcher den virkelige verden, der således har forandret sig, inden projektet er blevet færdigt.

Benyttes Zachmans rammeværk i forbindelse med EA, afhænger brugen af rammeværket af

den specifikke organisation. Det vil således være tilfældet, at kun dele af rammeværkets

perspektiver og aspekter er relevante. F.eks. er det ikke i alle organisationer, at ”builder” og

”subcontractor’s” perspektiverne er nødvendige, da disses arbejde ikke hidrører den specifikke

virksomhed. Dette kunne være tilfældet, hvis f.eks. udviklingen og implementeringen af nye

IT-systemer i en virksomhed er outsourcet, så virksomheden ikke selv skal håndtere dette. De

skal kun beskrive deres ønsker overordnet og som sådan ikke forholde sig til den tekniske del.

13


Rammeværket er ca. 17 år gammelt fra dets oprindelse. Selve opbygningen af rammeværket

består af generiske og tidløse dele, som formentlig gør, at det stadig eksisterer efter så mange

år. Dette på trods af de mange forandringer, der er sket inden for IT. De udetaljerede celler gør,

at de kan passe til mange situationer, hvor de vigtige aspekter er bredt brugbare. Det vil således

næppe være muligt at finde forhold, der ikke kan placeres under et af disse områder.

3.2. Afrunding

Et rammeværk er ikke en arkitektur i sig selv, men den kan understøtte en sådan. Med sin

metamodel skaber Zachman et rammeværk, som kan udfyldes af en organisation, og det bliver

dermed en støtte for organisationen i dens forsøg på at skabe sig et overblik over selve

virksomheden og dennes systemer. Dette vil give organisationen indblik i, hvordan den kan få

dens IT-portefølje til at understøtte den overordnede forretningsvision effektivt.

Zachman har forsøgt at skabe et rammeværk, der giver organisationer et overblik over deres

informationssystemer ud fra forskellige perspektiver og aspekter. Resultatet bliver

selvstændige celler i en matrix, hvor cellernes indhold udgøres af artefakter. I den idelle verden

eksisterer der kun primtive artefakte, der nøjagtigt passer ind i en enkelt celle. Fordelen ved

dette er, at indholdet let kan ændres, uden at det påvirker andre celler. Desværre ser

virkeligheden ikke sådan ud, og Zachman erkender også, at der eksisterer sammensatte

artefakter, der går på tværs af cellerne i rammeværket. Dette kan give problemer, når behovet

for ændringer opstår i de enkelte celler, og en organisation bør derfor i størst muligt omfang

normalisere de artefakter, der går på tværs af flere celler, så organisationen fungerer så agil

som muligt.

Zachman går i sit rammeværk ikke i detaljer med de ønskede leverancer i de enkelte celler,

men giver i stedet et generelt overblik over, hvordan organisationer kan få struktur på deres

systemer, således de ikke ender i et IT-kaos. Det betyder, at rammeværket er metode- og

procesuafhængigt, og det er derfor op til organisationerne selv at anvende rammeværket, som

de finder det mest rigtigt i forhold til organisationen.

14


4. Herzum – EA og Rammeværker Formålet med EA er, at organisationer bedre kan håndtere deres IT i relation til deres

forretning. En virksomheds IT-portefølje kan synes meget uoverskuelig og kompleks, og ofte

træffes isolerede IT-beslutninger, der ligger langt fra organisationens egentlige behov.

Konsekvenserne af at der ikke eksisterer et overordnet mål, som IT-beslutninger styres efter,

kan blive enorme for organisationen og kan resultere i, at virksomhedens IT-portefølje bliver

meget kaotisk. EAs rolle er derfor at støtte organisationer i dens beslutninger omkring IT, så

disse understøtter den generelle forretning bedst muligt på baggrund af standarder, principper,

koncepter, guidelines m.v. EA kan dog være en meget uoverskueligt opgave at skulle

iværksætte, og mange virksomheder fejler direkte i deres forsøg på at implementere EA. Det er

derfor utrolig vigtigt at forstå, hvad en EA-proces indeholder, hvordan en sådan aktivitet gribes

an, og hvad organisationen ønsker at få ud af arbejdet.

Herzum påpeger, at EA ikke kun handler om at få defineret en arkitektur, der kan støtte en

forretning i dens fremtidige IT-beslutninger, men også om at transformere eksisterende

systemer, så de opfylder kravene, defineret i arkitekturen. Hvis ikke en virksomhed erkender

dette, vil implementeringen af EA sandsynligvis fejle. Herzum mener således, at det er en

misforståelse af EA-konceptet at benytte Zachmans sammenligning mellem etableringen af en

EA og konstruktionen af en bygning. Selvom der er et par ligheder arkitekturerne imellem, er

den store forskel, at bygningsarkitekturen er alt for snæver. Han peger på den forskel, at

bygningsarkitekturen ikke indeholder den dynamik, EA gør. Han mener i stedet, at urbanisme

er en bedre analogi i forsøget på at tydeliggøre, hvad EA handler om. I en byplanlægning

tillades det, at systemer udvikles uafhængigt af hinanden over tid samtidig med, at der forsøges

opnået en overordnet vision. Yderligere påpeger Herzum, at der ikke eksisterer nogen

organisation, der i dag opbygger deres IT-portefølje fra bunden. Derimod forsøger

organisationerne at ændre deres eksisterende IT-portefølje, så de overholder de principper,

standarder, guideliens m.v., der bliver specificeret i deres EA.

Spørgsmålet er dog, om Zachmans sammenligning med en bygning skal tages så bogstaveligt.

Den bruges blot til at illustrere, at der er mange forskellige perspektiver involveret i en

arkitekturproces, som formentlig alle har forskellige referencerammer og tilgange til, hvordan

en løsning skal opbygges. Urbanismen er dog en bedre analogi, idet den skaber en mere

15


realistisk sammenligning. Til gengæld er den langt mere abstrakt og dermed vanskeligere at

forstå. Bygningsanalogien er således mere pædagogisk, når det grundlæggende budskab om de

forskellige perspektiver og referencerammer skal illustreres. Yderligere kan Zachmans

rammeværk sagtens anvendes, hvor en virksomhed allerede har systemer, da det uden

problemer er muligt at tage udgangspunkt i en organisations nuværende situation (”as is”).

Ideen bag EA er ikke at skabe en superstruktur, men derimod at fremme agilitet i en

organisation, så denne er forberedt på lettere at kunne håndtere forandringer optimalt. Det sker

eksempelvis ved, at de forskellige grupper kun arbejder med den del af EA, der er relevant for

dem. Det skal foregå problemløst, således at EA er så usynlig for en organisation, at det ikke er

klart, at den bruges, men EA skal ligge i baggrunden som en bevidst styring, der driver hele

organisationen mod samme mål.

Opbakning fra ledelsen er altafgørende for at opnå konsensus omkring implementeringen af

EA på tværs af organisationen. Er de positive overfor de forandringer, EA bringer med sig, vil

ændringerne lettere kunne forankres ud i organisationen, og det vil alt andet lige være mindre

kompleks at håndtere den uundgåelige modstand, der vil opstå. Der vil dog altid opstå politiske

situationer, når der sker forandringer i en organisation, hvorfor det er vigtigt, at EA-teamet er

klar over, hvem der er dets stakeholdere samt hvem af disse, de bør bruge tid og kræfter på.

Derudover kræver EA også involvering af både tekniske og forretningsmæssige folk for at

kunne opnå en forståelse af begge områder og dermed få dem integreret, som er formålet med

EA.

Udviklingen af en EA-referenceramme er et langsigtet projekt med en varighed lige fra

måneder til år alt afhængig af EA-omfanget og den specifikke organisation, der ønsker at

etablere en EA. EA skal indeholde både ”as is” og ”to be” situationer, og scopet skal være

bredt, da det skal dækker hele organisationen, hvor fokus dog skal være på udvalgte områder.

Eksempelvis bør EA fokuserer på de aktiviteter, der har et højt afkast. Dels er økonomisk

overskud en forudsætning for organisationens overlevelse, men lige så vigtigt i et EA-

perspektiv, da det hurtigt kan bevise vigtigheden af et EA-projekt. Også EA-arkitekternes

intensive deltagelse i et projekt bør være i fokus, og de skal derfor definere, hvor lang tid, de

arbejder på hvert projekt. Det er væsentlig, at projektet ikke bliver afhængigt af arkitekternes

personlige indsats. Når den definerede periode er overstået, skal de kunne gå videre til næste

projekt, mens det forladte projekt kan sigte mod nye mål. Et projekt behøver faktisk ikke være

16


løst fuldstændig perfekt, inden arkitekten forlader det. I stedet kan det være langt mere

udbytterigt at satse på en pragmatisk løsning, der således samtidig er et mere realistisk projekt.

4.1. EA-modenhedsfaser

For overhovedet kan at kunne kombinere en organisations forretningsstrategi og IT-strategi og

ikke mindst få etableret en agil IT-portefølje kræver det et vist niveau af modenhed. Herzum

giver et bud på dette ved at opstille fem EA-modenhedsfaser, som alle skal gennemleves af en

organisation for at opnå det han kalder ”nirvana”:

1. Inception: I den første modenhedsfase foregår der muligvis en række enterprise aktiviteter,

der vil have fokus på enkeltstående isolerede projekter. Behovet for en egentlig EA-

referenceramme eksisterer ikke. Fokus vil være på teknik, da holdningen er, at alt kan løses

gennem teknologi. Der eksisterer ingen mekanismer, som kan hjælpe med at identificere

projektsynergier.

2. Classification: På dette stadie er der stadig ikke den store sammenhæng mellem IT-

strategien og selve forretningsstrategien. Der vil være etableret et EA-team, som vil forsøge

at udarbejde en form for referencearkitektur. Fokus vil være på at indsamle og organisere

eksisterende leverancer og informationer. Der vil ofte blive udarbejdet et overordnet

billede, der giver et overblik over virksomhedens eksisterende IT. Dette er en start på at

håndtere IT som en forretning. Dog har IT i denne modenhedsfase ikke nogen betydelig

indflydelse på forretningen. Organisationerne vil ofte bruge Zachman eller et andet EA-

rammeværk.

3. Blueprinting: I denne fase behandles EA-projektet som et strategisk organisationsprogram

med blandt andet eget budget. Organisationen starter på at opbygge en referenceramme.

EA-teamet forsøger at beskrive den nuværende situation (”as is”) og de langsigtede ønsker

(”to be”), en virksomhed har for deres IT-portefølje. Her bliver de enkelte EA-aktiviteter

relateret til hinanden, da virksomheden er klar over denne afhængighed. EA-konceptet er

accepteret og bruges også uden for EA-teamet som en del af det daglige IT-arbejde.

Organisationen begynder på dette niveau også at støtte sig til EA i forbindelse med

strategiske beslutninger. EA bruges således som en styringsmodel i forbindelse med at

træffe beslutninger i relation til individuelle projekter. Dette gør, at disse projekter

begynder at passe ind i organisationens overordnede vision. Ifølge Herzum begynder de

17


simple arkitektoniske referencerammer, som f.eks. Zachman til en vis grad at miste deres

brugbarhed og erstattes med rammeværker, som Herzum mener tilhører den gruppe, han

benævner anden generations EA-rammeværker. EA begynder at tilbyde enterprise

komponenter eller services, disse er dog endnu ikke så udbredt indenfor organisationen og

mangler stadig at blive modnet.

4. Integration: Fokus er i denne fjerde fase på at få IT til at understøtte forretningen. Målet er

et højt niveau af integration på tværs af organisationen. Organisationen vil på dette niveau

være i stand til at dreje arkitekturen i en strategisk retning som f.eks. at mindske IT-

porteføljens kompleksitet, og Zachmans rammeværk vil typisk være for grundlæggende at

bruge her. Udvikling af nye eller gamle systemer, indkøb eller outsourcing bliver besluttet

med det formål at overholde en specifik IT-strategi og referencearkitektur. Der vil i denne

fase være en strategi, der har til formål at hjælpe med at øge integrationen mellem IT og

forretningen. Fokus vil være på en komponentbaseret fremgangsmåde på tværs af

organisationen. Dette vil med tiden garantere minimal data- og applikationsoverlapninger.

5. Optimization: Organisationen har på dette stadie opnået et vis niveau af integration,

kompleksiteten af organisationens IT-portefølje er blevet betydelig reduceret, og IT-

strategien understøtter forretningsstrategien. Alle de værktøjer, standarder, principper m.v.,

der er nødvendige for at kunne håndtere IT som en forretning, er etableret.

Forretningsprocesserne vil konstant blive optimeret, og forretningen har således opnået en

vis agilitet. Referencearkitekturen er nu udført i praksis og er realiseret i den aktuelle IT-

portefølje. Der er hjælp at hente på alle niveauer af IT, og nye forretningsstrategier kan

virkeliggøres med en lille risiko. Herzum beskriver denne fase, som den ideelle fase

(”nirvana”), men er ikke bekendt med nogen firmaer, der på nuværende tidspunkt befinder

sig på dette niveau. Han mener dog, at mange virksomheder forsøger at udvikle sig i denne

retning.

4.2. EA rammeværktøjer

Et moderne EA-rammeværk skal ifølge Herzum indeholde forskellige vigtige karakteristika.

Blandt andet skal det adressere de forskellige karakteristika og niveauer af IT. Derudover skal

rammeværket være i stand til at udvikle sig i takt med, at en virksomhed udvikler sig igennem

de forskellige faser, hvor et moderne rammeværk skal fungere som bindeleddet mellem

forretningen og IT.

18


En rammeværksmodel er en stor hjælp til at defineret omfanget af det specifikke EA-projekt.

Derudover kan det også være en stor støtte i selve udførelsen af EA-arbejdet. Herzum skelner

mellem første og anden generations EA-rammeværker. Under første generation lister han

blandt andet Zachmans rammeværk, og under anden generations rammeværker nævner han

COSM (Component-Oriented Software Manufacturing), der er Herzums eget produkt.

4.2.1. EA-første generationsrammeværktøj - Zachman

Zachmans rammeværk er ifølge Herzum et første generationsrammeværk. Dette rammeværk

har haft stor indflydelse på forståelsen og udviklingen generelt omkring EA og har samtidig

haft stor fokus på kompleksiteten af et sådant arbejde. Det er ikke et rammeværk, der søger at

løse et problem, da det således ikke indeholder metoder eller processer i forbindelse med

udarbejdelsen af en EA-aktivitet. Det giver således heller ikke svar på, hvad der specifikt skal

leveres ud fra de problemer, en organisation måtte have. Det betyder, at EA-teamet ud fra

kortlægningen af organisationen selv må forholde sig til de ønskede resultater. Herzum mener

således, at Zachmans rammeværk ikke hjælper en organisation med at få individuelle projekter

til at understøtte en global vision. Der er altså ikke tale om en støtte til at sammenkoble en IT-

strategi med dens forretningsstrategi for de enkelte projekter.

Herzum finder, at det både er en svaghed og styrke, at rammeværktøjet ikke definerer, hvilke af

organisationens informationer, der skal puttes ind i de enkelte celler samt det nødvendige

detaljeringsniveau. Det gør rammeværket fleksibelt og lader det være op til den enkelte

virksomhed at afgøre, hvad der passer bedst til dennes behov. Samtidig kan denne valgfrihed

synes utrolig uoverskuelig og kompleks for en organisation. Desuden mener Herzum, at

Zachman beskæftiger sig med de traditionelle arkitektoniske dimensioner som applikationer,

data og netværk. Dette kan give nogle organisatoriske problemer for virksomheder, der hører

til noget oppe af modenhedsstigen. Disse firmaer kan ikke sådan uden videre opdele data og

applikationer skarpt, men ville foretrække en komponentbaseret fremgangsmåde, da denne

tager højde for den måde mere modne organisationer er opbygget på inklusiv deres systemer.

Ifølge Herzum tilhører Zachmans rammeværk klassifikationsfasen (”Classification”). Det er et

rammeværk, der ofte er brugt i en organisations spæde forsøg på at påbegynde et EA-arbejde.

Dog vil Zachmans rammeværk allerede i denne fase ikke være tilstrækkeligt, og det vil allerede

her være nødvendigt, at virksomhederne udvider rammeværket, hvis det skal være

fyldestgørende. Herzum påpeger, at rammeværket bærer præg af at være over ti år gammelt.

19


Basiselementerne af IT er de samme, men arkitekturperspektiverne har udviklet sig markant.

Han siger, at Zachmans rammeværk i dag betragtes som en statisk klassifikation af traditionelle

IT-leverancer, der er baseret på traditionelle dimensioner.

Herzum konstaterer, at Zachman opridser nogle vigtige perspektiver. Han påpeger, at det, der

gør nogle rammeværker bedre end andre, er blandt andet, hvad rammeværket lægger vægt på

og dets omfang. Disse faktorer har dog udviklet sig over tid, og dem, der var vigtige for ti år

siden, er ikke de samme, som dem, der lægges vægt på i dag, og Zachmans rammeværk er

således ifølge Herzum ikke tilstrækkeligt for mere EA-modne organisationer.

4.2.2. EA-anden generationsrammeværktøj – COSM

COSM er en agil softwarefremstillingsmetode udviklet af Herzum Software. Den stammer

tilbage fra 1992 og er meget inspireret af Zachman. COSM var det første fuldstændig

komponentbaseret rammeværk, hvilket blandt andet betyder, at rammeværket har stor fokus på

agilitet og gode skalleringsmuligheder.

Figur 2 - Illustration af, hvor COSMs komponentbaseret rammeværk befinder sig blandt tidens

hovedarkitektoniske modeller.

Kilde: Herzum, Peter:”Applying Enterprise Architecture”

COSM er i de senere år blevet udvidet og ændret således, at det også tager hånd om EA og IT-

strategi. Herzum mener, at denne fremgangsmåde er den første, der tilbyder både et

20


rammeværk til at klassificere EA-leverancer samtidig med, at den også indeholder processer og

teknikker, der linker IT-strategien, forretningsstrategien og EA sammen. Modellen kan hjælpe

en virksomhed gennem de forskellige modenhedsfaser fra ”inception” til ”optimization”.

COSM består af forskellige områder, der er nødvendige ud fra et organisationsperspektiv:

”Business Architecture”: Fokusere på analyse og modellering af forretningen ud fra et

forretningsperspektiv.

”Functional Architecture”: Har fokus på de funktionelle aspekter i en IT-

portefølje, f.eks. videreudvikling eller indkøb af software.

”Structural Architecture”: Omhandler arkitektoniske beslutninger, mønstre,

guidelines og standards, der er nødvendige for at

definere, vedligeholder og udvikle en portefølje.

(Applikationsarkitektur).

”Technical Architecture”: Fokuserer på tekniske beslutninger såsom tekniske

mønstre, beslutninger omkring teknologier,

middleware, databasemanagement systemer og

infrastruktur, der er acceptable for virksomheden.

”Management Architecture”: Indeholder arkitektoniske beslutninger, mønstre,

leverancer, værktøjer og guidelines, der hjælper en

organisation med at håndtere deres portefølje

effektivt.

Ovennævnte synspunkter placerer de mest vigtige EA-leverancer i en kontekst. Dette giver et

godt overblik over de forskellige dele af organisationen.

Herzum påpeger desuden i forbindelse med COSM-rammeværket, at simple Excel og

PowerPoint diagrammer, som også er indeholdt i COSM, sandsynligvis ikke vil være så

brugbare i et modent EA-arbejde. Dog kan de være utrolig vigtige i relation til ledelsen, da de

er lettere at forstå og vil inspirerer til en diskussion på deres niveau. Igen kan vigtigheden af

dette ikke undermineres, da ledelsen sidder med nøglen til at få EA implementeret succesfuldt i

organisationen.

21


4.3. EA-strategi

EA går ifølge Herzum overordnet ud på at sammenkoble IT-strategien med

forretningsstrategien. Derudover handler det også om at få defineret en IT-strategi og

sammenholde IT-strategien, strategiske programmer samt individuelle projekter.

Herzum påpeger, at kun i en ideel verden er det muligt at definere EA ud fra en

gennemarbejdet forretningsvision og strategi. En organisation skal være mindst i

”Blueprinting” modenhedsfasen for konkret at kunne sammenholde forretnings- og IT-

strategien, inden da er den simpelthen for organisatorisk uerfaren. Først i integrationsfasen er

det muligt at sammenholde de to strategier objektivt og ud fra dette foretage velovervejede

beslutninger. Mange IT-organisationer definerer faktisk i dag deres IT-strategi uden at tage

hensyn til eller være vidende om forretningsstrategien. Det betyder dog ikke, at en IT-

organisation ikke kan forberede IT-strategien til at være i overensstemmelse med

forretningsstrategien. Dette kan ske ved, at organisationen etablerer en agil og

forandringsvenlig IT-strategi, der er moden nok til at kunne håndtere de forandringer, der måtte

ske i organisationen. Fokus kunne f.eks. være på at minimerer IT-omkostninger og

kompleksiteten i organisationens IT-portefølje. Derudover bør fokus være på, at IT- services

skal deles så vidt muligt på tværs af organisationen, når dette er optimalt. Det er i den

forbindelse vigtigt, at de, der definerer IT-strategien, er bekendt med dens omfang først og

definerer dens fokus senere. EA-arkitekter har kun mulighed for at fokusere på en begrænset

mængde områder hvert år, og arkitekterne bør ifølge Herzum ændre deres fokus løbende. På

den måde bliver EA-aktiviteten mere overskuelig, og det bliver også mere synligt for

organisationen, at EA-processen bevæger sig.

Det kan være svært for en organisation at træffe velbegrundede beslutninger med hensyn til,

hvilke projekter, der skal sættes i gang og i hvilken rækkefølge. COSMs strategiske

projektidentifikationsproces vil således hjælpe organisationen med at træffe sådanne

beslutninger. Modellen er illustreret nedenfor.

22


Figur 3 – COSMs projektevalueringsmodel

Kilde: Herzum, Peter:”Applying Enterprise Architecture”

Der skal etableres en beslutningsdygtig gruppe bestående af både tekniske og forretningsfolk i

organisationen, som vurderer de forskellige projekter i projektporteføljen. De evaluerer de

enkelte projekter ud fra et sæt af kriterier (”lenses”), der er defineret på baggrund af

organisationens EA. Kriterierne kan være specifikke IT-principper, som projektet skal

overholde, f.eks. kan der være krav om en komponentbaseret arkitektur. Modellen giver

således en organisation mulighed for at strukturere dens IT-portefølje mere effektivt i

forbindelse med en vurdering af de forretningsmæssige fordele ved projektet. Derudover kan

modellen også være en hjælp for organisationen i forbindelse med en vurdering af eventuelle

synergier eller dobbeltarbejde projekterne imellem, hvilket også er et af målene med en

virksomheds EA.

4.4. Afrunding

Ifølge Herzum vil EA være en stor hjælp for de enkelte virksomheder i relation til at styre

deres IT-portefølje mod en overordnet forretningsvision. For at en virksomhed kan opnå dette,

skal denne dog være på mindst ”Blueprinting” modenhedsniveauet. Efterfølgende bliver EA-

arbejdet mere komplet og kan derfor også yde mere til organisationen. Herzum er inde på

forskellige generationer af rammeværker og fastslår blandt andet, at Zachmans rammeværk er

forældet. Han peger således på sit eget komponentbaseret rammeværktøj ”COSM”, og

23


konstaterer, at det er mere fuldendt, da det er en større hjælp i klassifikationen af EA-

leverancer og hjælper EA-teamet mere i selve udarbejdelsen af EA-arbejdet.

24


5. Analyse af VA Veteran Affairs (VA) er den myndighed, der står for at servicere krigsveteraner og deres

familier i USA. De har omkring 70.000 ”kunder” og er en af USAs største civile myndigheder

med cirka 225.000 ansatte på i alt 6.000 lokationer. VA har beskæftiget sig med EA i en

årrække og anses i dag som værende en af de bedste på EA-området. De betragter EA som et

middel til at skabe sammenhæng mellem deres IT-portefølje og forretningsvision og benævner

denne omfattende aktivitet One-VAs EA. One VAs EA er en fortsættende aktivitet, der således

har stor indflydelse på organisationens styring af IT og er medvirkende til, at VAs EA-

modenhed forbedres løbende.

Fokus i nærværende afsnit vil være på VAs håndtering af EA i dag på baggrund af deres

implementeringsdokument ”One-VA Enterprise Archiecture Implementation Plan: FY 2003”

(February 6, 2003). Omdrejningspunktet er her at ændre VAs ”line-of business-centric”

udgangspunkt til en ”veteran-centric” indstilling, hvor forretningsprocesserne søges optimeret

med det for øje at servicere ”kunderne” bedst muligt. Vi indleder med en kort introduktion af

årene, der leder op til VAs etablering af EA, da dette vil bidrage til en forståelse af det

komplekse arbejde, VA har været igennem for at nå til det forholdsvis højde EA-

modenhedsniveau, de er på i dag.

5.1. Historik – motivation for etableringen af en EA

VA er en meget kompleks organisation, der tidligere udviklede IT systemer vertikalt langs

organisatoriske linier. Dette resulterede i, at der blev suboptimeret lokalt i organisationen, da

fokus ikke var på at understøtte forretningens overordnede strategiske mål og dermed

kundernes behov, men derimod på at nå effektivitet isoleret set i afdelingerne. Det resulterede i

utrolig mange ikke-integrerede IT-systemer, der blandt andet betød indtastning af de samme

data op til flere gange, hvilket medførte tunge arbejdsgangene og store fejlkilder. VAs IT-

portefølje var således meget kompleks og kaotisk, og på den baggrund besluttede VA i 1992 at

udvikle en åben systemarkitektur med en 5-10 års transformationsstrategi, hvor fokus var på

automatisering.

25


I midt 90’erne vedtages ”Clinger-Cohen Act6”, hvorefter VA nedsætter en IT-arkitekturgruppe

(”IT Architecture Team”), som i starten af 1997 lancerer projektet ”Information Technology

Architecture (ITA)”, der skal sørge for interoperabilitet og deling af data på tværs af

organisationen. Et af hovedresultaterne af ITAs arbejde er en solid og effektiv infrastruktur,

som er integreret på tværs af organisationen: ”We now have a network that supports all 6,000

locations at speed of light”, udtaler VAs CIO, Ed Meagher7. Det var en meget trættende og

kompleks opgave, at få VAs infrastruktur op på dette niveau, men en absolut nødvendighed

inden VA kunne begynde at fokusere på at optimere deres forretningsprocesser.

I starten af det 21. århundrede skifter fokus markant fra ITA til EA. Omdrejningspunktet er nu

at få VAs IT-portefølje til at understøtte forretningen, hvilket resulterede i en erkendelse af, at

det krævede en større kortlægning af VA for at ændre de nuværende systemer til at opfylde de

ønskede mål. Strategidokumentet ”Enterprise Architecture: Strategy, Governance &

Implementation” (august 2001) udgives blandt andre. Dokumentet påpeger direkte, at VA skal

have etableret en EA, der skal adressere de problemer, der eksisterer i VAs IT-portefølje

således, at systemerne bedst muligt understøtter forretningen og kunderne. VAs store fokus er

nu ”veteran-centric”.

Før ovennævnte strategidokument kunne VA karakteriseres som ”line of business-centric” med

19 hovedsystemer (services), der var opbygget som siloer, hvilket betød, at der ikke var stor

integration systemerne imellem. Billedet, VA præsenterede for dens kunder, var således et

ukoordineret billede, hvor data ikke var opdateret eller konsistente, hvilket fik VA til at virker

meget ineffektiv og til tider bureaukratisk. F.eks. kunne veteranerne ikke nøjes med at registrer

én gang for at få adgang til VAs services, men skulle igennem den mere eller mindre samme

registreringsproces 19 gange. VA ønsker at få mere fokus på kundernes behov og i den

forbindelse også udnytte internetteknologiens mange muligheder som f.eks. netværksbaserede

forretningsmodeller, så kunderne selv er i stand til at søge informationer på alle tider af døgnet.

Et af hovedformålene med One-VAs EA er således, at denne skal være en hjælp i forbindelse

med at informere, guide og håndtere ved beslutninger specielt i relation til IT, hvor fokus vil

6 The Clinger-Cohen Act hedder oprindeligt ”Information Technology Management Reform” og omhandler de krav, der stilles i forbindelse med erhvervelsen og håndteringen af IT i de offentlige organer. Der opstilles både krav til, hvad udvalgte ledere i organerne skal udføre, hvor disse samtidig bevilliges højere autoritet i forbindelse med at erhverv IT-ressourcer. 7 Telefoninterview med VAs CIO Ed Meagher, Friday 14 May 2004

26


være på en horisontal udvikling af IT, der har fokus på koordination og integration på tværs af

organisationen, som bliver drevet af den overordnede vision.

Den overordnede missionen for VAs EA er, at udvikle og implementere en agil One-VA IT-

arkitektur, hvor kompleksiteten af VAs IT-portefølje mindskes og fokus flyttes fra at være

”line of business-centric” til at være ”veteran-centric”. Denne forandring ville ifølge VAs CIO,

Ed Meagher, ikke være mulig, hvis VA ikke var fuldt ud overbeviste om, at de ville være i

stand til at håndtere en så utrolig kompleks proces. Det er således kun muligt på grund af det

infrastrukturarbejde, VA allerede har udført. VA har nu blandt andet fuldt ud styr på deres

netværk og dataprocesser inklusiv, hvor de enkelte data bruges. Dette betyder, at hvis der

implementeres ændringer i forretningsprocesserne, ved VA helt præcist, hvordan det påvirker

andre berørte systemer. Derudover påpeger Ed Meagher kraftigt, at EA er en forretningsproces

og ikke en teknikproces, da teknikken i VA kun er en funktion, der skal understøtte

forretningen. Udviklingen af One-VA-arkitekturen er således en stor, tidskrævende og

vedvarende aktivitet, der vil involvere mange folk, og som kræver løbende opdateringer og

revideringer i mange år fremover.

5.2. Introduktion til VAs EA implementeringsplan

VAs første EA implementeringsplan er fra 2002 ”One-VA Enterprise Architecture

Implementation Plan: FY 2002”. Fokus i nærværende opgave vil dog være på VAs 2003

implementeringsplan ”One-VA Enterprise Archiecture Implementation Plan: FY 2003”

(February 6, 2003), der således giver det bedste indtryk af, hvor langt VA er nået i deres EA-

proces. Afsnittet ”EA-udviklingsindsats” vil dog inkludere arbejdspunkterne for år 2002 i

forhold til 2003.

Implementeringsplanen bliver årligt opdateret, og udstikker retningslinierne for, hvordan VA

skal integrere IT på en sådan måde, at systemerne understøtter forretningen. Planen er et

strategisk dokument, der indeholder principper, guidelines og standarder m.v. for, hvilke

projekter, der skal sættes i gang, hvem der skal udføre arbejdet, og hvornår det skal være

færdigt. Implementeringsplanen fungerer således som ”bibelen” for EA-arkitekterne,

projektlederne, IT-managere og andre involveret i udarbejdelsen af One-VAs EA. Planen

dækker det nuværende år (regnskabsår), hvor fokus er på igangværende projekter; det følgende

budgetår, hvor fokus vil være på at støtte budgetterede projekter gennem de første par

27


milepæle; samt det efterfølgende planlægningsår, der vil inkludere nye højtprioriterede

projekter.

Essensen i One-VAs EA er at få defineret VAs nuværende situation (”as is”), deres ønskede

miljø (”to be”), og hvordan de kommer fra ”as is” til ”to be” situationen. VA har især stor

fokus på deres ”to be” situation, dog er de godt klar over, at de ikke kan undervurdere deres ”as

is”, da ikke alle eksisterende systemer skal migreres til noget nyt. Nogle af de gamle systemer

vil bestå, hvorfor de også skal beskrives, da de vil være en del af den samlede IT-portefølje.

VAs CIO påpeger, at det kan være utrolig svært for en organisation at kortlægge dens

eksisterende situation, da dette kræver 100% ærlighed omkring, hvordan tingene ser ud og

fungerer samtidig med, at der er en politisk dimension at tage hensyn til i forbindelse med,

hvorfor der er forskellige måder at opbygge systemer på i VA og forskellige tildelinger af

ressourcer til systemerne. Til at styre denne komplekse opgave har VA nedsat rådet Enterprise

Architecture Council (EAC), også kaldet ”deviants”, som ledes af en chefarkitekt (Chief

Enterprise Architect), og det består af både forretnings- og teknikfolk.

VAs CIO, Ed Meagher, gør opmærksom på, at det var utrolig vigtigt, at medlemmerne i dette

råd var beslutningsdygtige, da det ville være dem, der skulle træffe mange vigtige beslutninger,

der ville berøre VA i fremtiden. Ed Meagher benævner således dette råd ”governance board”.

Medlemmerne af rådet skal blandt andet fungere som guider i forbindelse med, at VA migrerer

fra deres nuværende situation til de ønskede mål. De skal således også være dem, der påpeger

eventuelle problemer, der opstår, når f.eks. gamle systemer skal migreres til de nye

arkitekturer. Blandingen af forretnings- og teknikfolk betyder, at organisationen bliver bredt

præsenteret. Dette vil uden tvivl styrke koblingen mellem IT og forretningen, når disse to

gruppe sammensættes i et råd og dermed bliver tvunget til at træffe beslutninger sammen.

Yderligere sidder rådet med ansvaret for, at VAs EA-arbejdet styrer mod de definerede mål,

hvilket er et ekstra incitament for de to grupper til at samarbejde.

Fremgangsmåden, som VA har valgt i forbindelse med at opbygge deres EA vidner om, at de

er klar over, at EA ikke er et letoverskueligt projekt, der tilfældigt kan udvikles i de enkelte

afdelinger. De er meget bevidste om, at det kræver overordnede retningslinier og styring for at

få så stort et projekt implementeret succesfuldt i organisationen. Desuden indikerer bevilligede

ressourcer til at få oprettet en decideret EA-afdeling opbakning fra ledelsen, hvilket også

tydeliggør EA-processens beståen og seriøsitet.

28


5.3. Udvikling af arkitektoniske principper

VA har defineret de overordnede retningslinier for deres EA på ledelsesniveau, idet

chefarkitekten, CIO’en, Information Technology Board’et og EAC-rådet har udarbejdet

nedenstående arkitektoniske principper, der kortlægger organisationens IT-vision og

strategiske planer.

• One-VAs EA skal være i overensstemmelse med formålet: Omfanget,

planlægningen og definitionen af One-VAs EA skal stemme overens med den tiltænkte

brug arkitekturen.

• One-VAs EA skal være i overensstemmelse med loven: One-VAs EA skal overholde

de love, der berører EA.

• One-VAs EA skal facilitere teknologisk forandringer: EA skal tage højde for de

hurtige og store forandringer, der sker indenfor IT-området i dag.

• One-VAs EA skal understøtte VAs overordnede strategiske plan. Arkitekturen

opnår først sin maksimale værdi, når den støtter VAs strategiske forretningsplan.

• One-VAs EA skal facilitere arkitektoniske forandringer: VA skal altid have fokus

på at nå hen til den ønskede situation (”to be”). Da miljøet ikke er statisk, vil de

fremtidige mål forandres både på grund af, at nye mål opstår, når de gamle er nået, men

også på baggrund af alle de forandringer, der sker i omverdenen.

• One-VAs EA skal understøtte en tre til fem års planlægningshorisont: Grundet den

korte teknologilivscyklus og de mange nye IT-produkter, der hele tiden dukker op, vil

VAs fremtidige informationsbehov og tekniske infrastrukturkrav ændre sig løbende.

Derfor er det ikke muligt at planlægge ti år ud i fremtiden.

• One-VAs EA skal fremme standardiserede forretningsprocesser og et fælles

driftsmiljø: Dette vil blandt andet understøtte interoperabilitet og

omkostningsbesparelser.

29


• One-VAs EA-arkitekter skal udvikle og validere præcise arkitektoniske

informationer: Arkitekten skal sørge for at få fat i relevante data fra de personer, der

besidder denne specifikke viden.

• One-VAs EA skal facilitere fremtidig dataindsamling, dataopbevaring og

dataadgang: Data er nøglen til succes i en organisation, når den skal udføre sine

daglige rutiner og ikke mindst nå sine mål. Det er helt centralt, at ingen ejer data, men

at data i stedet er et fælles aktiv.

• One-VAs EA skal kontrollere afvigende teknologi: Det er vigtigt, at VA er fokuseret

på interoperabilitet i forbindelse med sine systemer. Derfor er de nødt til nøje at

udvælge og følge standarder i deres køb og udvikling af systemer, i modsætning til at

inddrage tilfældige teknologier.

Ovenstående principper udtrykker klart, at VA er en organisation, der er meget bevidst om,

hvad de vil have ud af deres EA-projekt. Arkitekturdefinitionerne giver et grundigt overblik

over, hvilke rammer arkitekturen skal indordne sig under. De tager både fat i de

organisatoriske, samfundsmæssige og politiske rammer samtidig med, at de også forholder sig

til de udfordringer, der ligger i teknologiens hastigt udviklende natur.

5.4. Fremgangsmåde i forbindelse med udviklingen af One-VAs EA i 2003

Det første skridt i udviklingen af One-VAs EA er at få identificeret og defineret

organisationens forretningsfunktioner (Enterprise Business Functions (EBF)) samt

nøglefunktionerne (Key Enabling Functions (KEF)). Eksempler på VAs EBF’er er økonomisk

kompensation, pension og uddannelsesstøtte. Eksempler på KEF’er er blandt andet

personaleafdelingen samt regnskabs- og finansafdelingen. EBF’erne er oftest eksternt

fokuseret, hvorimod KEF’erne sørger for en smertefri drift af organisationen både internt og

eksternt.

Det andet skridt er at nedbryde EBF’erne og KEF’erne til mere detaljeret subfunktioner samt

definere de tilhørende dataklasser inklusiv andre vigtige kriterier. Dette vil danne grundlag for

en identifikation af eventuelle overlappende, gentagende samt overflødige processer og data

30


funktionerne imellem. Fremgangsmåden i relation til ovennævnte opgaver vil være ens, og det

er nødvendigt at opnå enighed om et specificeret detaljeringsniveau. EA er en lang proces, hvor

fokus og prioriteringer vil skifte løbende, hvorfor fokus vil være på forskellige funktionelle

områder hvert år. VAs bevidsthed om, at fokus løbende vil og bør skifte, indikerer, at de ikke

har tænkt sig at dække hele virksomheden på én gang, men derimod udarbejde EA i bidder. De

vil således kunne fokusere på de vigtigste funktioner først inklusiv dem, der hurtigt giver

resultater, hvilket hurtigt vil bevise EAs berettigelse.

Det tredje skridt er at mappe de nedbrudte dele ind i et klassifikationsskema for dermed at

organisere de informationer, der er udviklet på organisationsniveauet. Zachmans rammeværk

bliver brugt i denne forbindelse, da dette giver mulighed for, at VA kan fokusere

opmærksomheden på de nødvendige niveauer i afdelingen (se afsnittet ”VAs brug af Zachman

rammeværket”).

Det fjerde skridt er at fokusere på udvalgte kritiske services og allokere funktioner til One-VAs

EA-baselines. Disse baselines er et af nøgleprodukterne i hele EA-arbejdet. De indeholder både

definitioner og begrænsninger indenfor hvilke, projektlederne skal udføre deres arbejde for at

være i overensstemmelse med VAs EA. VAs baselines identificerer funktioner, subfunktioner,

processer samt data allokeret til specifikke informationssystemer og sørger for, at der ikke sker

ens opgaver i flere systemer.

Det femte skridt er at opdatere en teknisk reference model (Technical Reference Model

(TRM)) og en IT standard profil (Information Technology Standards Profile (SP)), der skal

guide EA-arbejdet. Det er et sæt bygningskoder (forholdsregler som modellerne indeholder),

hvorunder hvert projekt skal udarbejdes. Disse modeller sammen med VAs baselines

indeholder de nødvendige retningslinier for at få VAs IT til at understøtte forretningen

effektivt. Det er altså utrolig vigtigt for VA at få udviklet principper, standarder, koncepter

m.v., som styrer udviklingen af IT for dermed at få hele IT-porteføljen til at nå samme mål.

Det sjette skridt går ud på at reviewe nye forslåede projekter i henhold til VAs EA for dermed

at sikre, at de er konsistente med arkitekturerne inklusiv de forretningsmæssige mål. De enkelte

projektledere for godkendte projekter er efterfølgende ansvarlige for, at nye arkitektoniske og

designartefakter udvikles i overensstemmelse med VAs EA herunder i forhold til relevante

baselines, TRM-modellen og SP. Dette er et eksempel på, at EA er en vedvarende aktivitet, der

31


hele tiden bør uddybes og opdateres i forbindelse med nye projekter for at være tidssvarende

med organisationen. Dette sikre VA sig blandt andet ved at kræve, at projektlederne er

ansvarlige for opdateringer i arkitekturerne, der vedrører deres projekter.

Der er etableret forskellige centrale overordnede modeller, blandt andet ”the Federal Enterprise

Architecture model”. Denne model tilskynder blandt andet, at de forskellige myndigheder kan

dele viden, erfaringer og ikke mindst overveje integration ministerierne imellem. Tanken er, at

alle myndighederne bidrager til opdateringen af modellen samtidig med, at de kan drage nytte

af informationerne indeholdt i modellen for dermed at skabe synergier på tværs af

organisationerne. Dog benytter VA sig faktisk ikke af modellen ifølge Ed Meagher. Han

påpeger, at de mapper deres erfaringer til modellen, men at den er for abstrakt at bruge for dem

på nuværende tidspunkt. Han mener ikke, at VA trods deres store fremskridt på EA-området, er

modne nok til at integrere med andre ministerier. Der er stadig mange uløste problematikker,

der skal løses i VA, inden de kan begynde at overveje at integrere med eksterne myndigheder.

Det vil således være alt for kompleks for VA at begynde at tænke i disse baner på nuværende

tidspunkt.

5.5. VAs brug af Zachman rammeværket

VA benytter Zachman rammeværket som en løftestang, der skal være en støtte i udviklingen af

VAs EA, herunder hjælpe med at organisere nøgleprodukter som f.eks. de funktionelle

baselines. VA bruger således et rammeværk til at få defineret deres EA, hvor modellen skal

være med til at skabe et overblik over organisationens ”as is” og ”to be” situationer, der gør det

letter for VA at udpege kritiske problemområder.

Brugen af Zachmans rammeværk tilbyder et klassifikationsskema, der gør det muligt at have en

fokuseret koncentration på udvalgte aspekter af et objekt uden at miste konteksten. Når en

organisation skal udvikle komplekse systemer, er der mange detaljer og forhold, der skal

overvejes på samme tid. Yderligere er det også farligt at isolere enkelte variabler og træffe

beslutninger udenfor en kontekst, da dette vil resultere i suboptimeringer, som det tidligere har

været tilfældet hos VA. De fandt Zachmans rammeværk som værende meget modent, da det

var dækkende, og det opfyldte således deres behov langt bedre, end de andre rammeværder, de

undersøgte. For at lette processen med at forstå og benytte et så omfangsrigt og kompleks

rammeværk, hyrede de Zachman i en periode og gjorde ham dermed en del af EA-processen.

Dette viser med al tydelighed, at det er utrolig vigtig for VA, at få mappet deres organisation

32


ind i Zachmans rammeværk på den mest optimale måde, da dette vil bidrage til det bedst

mulige grundlag, hvorpå de kan få optimeret deres IT på baggrund af deres ”as is” og ”to be”

situationer.

Hver række i rammeværket bruger VA til at udtrykke de forskellige interessenters perspektiver

i arkitekturen:

Række 1 (Planner) beskriver VAs vision og mission set fra ministerens (VA Secretary)

perspektiv. Dette gøres på baggrund af de EBF’er og KEF’er, der definerer afdelingens

arbejde. Ved udarbejdelsen af række 1, identificerer og definerer VA således relevante EBF’er

og KEF’er og karakteriserer dem ud fra blandt andet deres overordnede dataklasser, deres

interne og eksterne motivationer samt ud fra, hvor og hvem der udfører dem.

Række 2 (Owner) beskriver VAs forretningsprocesser ud fra linecheferne og stabschefernes

perspektiver. Række 2 er begrænset af række 1 og drevet af VAs forretningsplaner.

Overlapninger og overflødigheder i de forskellige funktioner vil blive identificeret, og via en

allokeringsproces vil de blive løst for derved at komme frem til nye definitioner af ”to be”

situationer for subfunktioner, processer og data ud fra et horisontalt integreret perspektiv. Dette

vil således forme de allokerede funktionelle baselines i forbindelse med udviklingen af nye IT-

systemer. Herzum fandt, at en skarp opdeling af data og applikationer kunne give problemer

for en virksomhed, hvis processer og data er meget integreret. Det tyder dog ikke på, at VA er

af den opfattelse, at Zachmans klassifikationsskema giver problemer i den retning. Det ser

mere ud til, at VA finder dette en styrke, og at det giver dem en mulighed for at opnå større

effektivitet i deres samlede IT-portefølje.

Række 1 og 2 udvikles ud fra et perspektiv, der dækker hele organisationen. Chefarkitekten er

ansvarlig for, at der genereres de nødvendige informationer i række 1 og 2. Denne person vil få

hjælp af EAC, som før nævnt vil bestå af både tekniske og forretningsmæssige repræsentanter

fra organisationens vigtigste linie- og stabsafdelinger. VA følger Zachmans rammeværktøj

meget nøje, hvor fokus er bredt i de øverste rækker, men hvor det således snævres ind, jo

længere ned de bevæger sig i rækkerne. Desuden er VA meget bevidst om, at alt afhængig af

det specifikke perspektiv kræver det involvering af forskellige medarbejdere. Længere nede i

rækkerne, vil projektlederne f.eks. spille en større rolle, end de gør i de øverste.

33


Række 3 (Designer) beskriver VAs logiske informationssystemer, der gælder på tværs af hele

organisationen set fra VAs individuelle projektlederes perspektiv. Arbejdet er begrænset af de

involverede personers perspektiver i række 1 og 2. I udarbejdelsen af række 3, vil VA

identificere og prioritere mulige strategiske projekter, hvor højt prioriterede projekter vil blive

valgt til at påbegynde i planlægningsåret. Der vil i den forbindelse kun være fokus på

milepælene 0 og 1 (se afsnittet ”One-VAs EA som en ”driver” i forbindelse med

investeringer”), hvorfor kun artefakter, der adresserer disse milepæle er nødvendige på dette

stadie. Artefakterne vil her definere detaljerede funktionelle og tekniske nødvendige baselines.

Chefarkitekten og projektlederne vil sammen sørge for, at de er integreret og konsistente med

forretningsbehovene.

Række 4 (Builder) beskriver VAs informationssystemer ud fra et IT-perspektiv, hvor de

ansvarlige er projektlederne. Arbejdet i denne række er begrænset af projektledernes detaljeret

funktionelle og tekniske nødvendige baselines og drevet af industriens ”best-practices”, der er

dokumenteret i VAs TRM-model og SP. Projektlederne er dem, der initierer udarbejdelsen af

artefakter i række 4 i form af tekniske designbaselines, der fungerer som forberedelse til

milepæl 2.

Række 5 (Subcontractor) beskriver VAs informationssystemer fra IT-integratorernes

perspektiv, og de ansvarlige er projektlederne. Artefakterne i denne her række er ”as-built”

konfigurationsbaselines, der er nødvendige for milepæl 3.

Række 6 (Functioning Enterprise) omfatter VAs operationelle forretningsfunktioner og

processer inklusiv deres understøttende informationssystemer set fra VAs brugere, kunder og

andre interessenters perspektiver. Perspektivet er begrænset af disse gruppers roller og ansvar

og drevet af VAs mål og ”performance measures”. De ansvarlige er driftspersonalet. I

udarbejdelsen af række 6 vil driftens ”performance measures”, defineret under udviklingen af

systemet, blive noteret gennem hele den periode informationssystemet er i drift.

For at optimere brugbarheden af VAs EA, vil VAs retningslinier for udvikling af artefakter

fokusere i størst muligt omfang på at fange de primitive elementer som beskrevet i Zachmans

rammeværk. Samtidig er det vigtigt, at de enkelte tekniske og forretningsmæssige

repræsentanter validerer indholdet af artefakterne. VA følger således Zachman meget stringent

på dette punkt, hvilket synes meget fornuftigt, da en forholdsvis korrekt anvendelse af

34


primitive og sammensatte artefakter er en god forudsætning for at opnå den fremtidige

fleksibilitet i en IT-portefølje, som VA søger. Derudover bærer det naturligvis også meget

præg af, at Zachman faktisk har været involveret i definitionen af fremgangsmåden i VAs

udarbejdelse af en EA.

Ifølge Zachman er rækkefølgen af kolonnerne ikke vigtige, da det afhænger af organisationens

formål med rammeværket. Kolonnerne har således forskelligt fokus for VA. F.eks. er kolonne

6 (”motivation/why”) dominerende for, at VA kan opnå deres mission, hvorimod kolonne 4

(”folk/who”) og kolonne 5 (”tid/when”) er vigtige i forhold til den overordnede arkitektur. VA

har valgt at udfylde kolonnerne i den rækkefølge, der er mest optimalt for deres virksomhed.

Det er helt i overensstemmelse med Zachmans procesfrie rammeværk, der lægger op til, at

organisationerne arbejder med rammeværket, som passer bedst til deres form.

VA har benyttet mulighederne for at udnytte rammeværket på en konstruktiv måde. Både fordi

de har været modne til at imødekomme de udfordringer, der opstår i forbindelse med en EA-

proces samtidig med, at de indså, at de havde brug for eksperthjælp, hvis de skulle være i stand

til at få det mest mulige ud af Zachmans meget omfangsrige og komplekse rammeværk. De var

klar over, at det var vigtigt, at de greb EA-processen korrekt an fra starten af for at være i stand

til at håndtere den komplekse opgave en EA-proces er. De har således tydeligvis gjort sig

mange overvejelser i forbindelse med udarbejdelsen af deres EA, og det udbytte, de får fra

rammeværket, vil de givetvis være i stand til at udnytte i forhold til fortsat at vedligeholde og

udvikle One-VA.

5.6. One-VAs EA som en ”driver” i forbindelse med investeringer

VA har udviklet en integreret procesmodel for VAs IT-projekter ”The Integrated Process Flow

for VA Information Technology Projects”. Modellen viser de forskellige trin i et projekts

livscyklus lige fra identifikationen af et behov til produktet er i drift.

35


Figur 4 – The Integrated Process Flow for VA Information Technology Projects

Kilde:”One-VA Enterprise Architecture Implementation Plan: FY 2003”, Department of

Veterans Affairs

Modellen består af fem milepæle, hvor One-VAs EA spiller en betydelig rolle. Eksempelvis

skal projektlederne i forbindelse med milepæl 0 fokusere på informationerne i række 1 i

Zachmans rammeværk for at få projektet godkendt. Projektlederne skal således definere, hvilke

af EBF’erne og KEF’erne projektet adresserer, hvor i organisationen projektet skal

implementeres, motivationerne, implikationerne i forhold til projektet og ikke mindst skal de

gøre opmærksom på, hvem der bliver berørt af projektet. Samlet set er det vigtigt, at

projektlederne udarbejder så meget information om projektet som muligt således, at det kan

vurderes, om projektet stemmer overens med One-VAs EA. VA har nedsat en

projektbeslutningsautoritet (Project Decision Authority (PDA)), som vil vurdere hver milepæl

review. De vil således sikre, at projektet er i overensstemmelse med VAs EA og dermed støtter

VAs forretningsmål. Formålet med modellen er meget lig COSMs strategiske

projektidentifikationsmodel, dog er VAs model noget mere detaljeret. Begge modeller fungerer

som styringsmodeller i en organisations beslutning om igangsættelse af IT-projekter, der søger

at understøtte den generelle forretning.

36


Ved milepæl 1 skal projektlederne primært fokusere på informationerne i række 2 i

rammeværket. Her skal de blandt andet beskrive, hvordan projektet passer ind i de allokerede

funktionelle baselines og integrationspunkter, der er indeholdt i række 2 i rammeværket.

Projekterne er således begrænset set i forhold til disse baselines, dog sikrer de en styring af

udviklingen af VAs IT-portefølje. I denne aktivitet vil der være mulighed for at validere VAs

EA. Når projekterne bliver mappet til EBF’erne og KEF’erne giver dette mulighed for at

identificere systemer, der udfører samme job, der ikke før er opdaget. Dette betyder således

også, at VAs EA jævnligt bliver opdateret og dermed modnet.

I milepæl II er projektledernes hovedfokus på række 3 og 4 i rammeværket. På dette tidspunkt

skal projektlederne have færdiggjort udviklingen af de detaljeret tekniske og funktionelle

nødvendige baselines for deres projekt, hvilket er fokus i række 3. De skal også starte arbejdet

svarende til række 4, der indebærer en definition af designbaselines, hvor kravene i TRM-

modellen og SP skal overholdes.

Når et projekt når hen til milepæl III, er målet at opnå implementeringsgodkendelse.

Projektlederne skal have færdiggjort række 4 og 5 i Zachmans rammeværk, der viser designet

og de faktiske konfigurationsbaselines. De skal også have defineret ”performance metrics”, der

skal indsamles under driften af informationssystemet og dermed fungere som basis for

evalueringen af, om de fastsatte mål er opnået, svarende til række 6 i rammeværket.

Milepæl IV går kort fortalt ud på at vurdere systemerne, efter de er implementeret.

VAs integrerer procesmodel viser tydeligt, at VA har operationaliseret deres EA. De har

formået at få omsat deres EA-mål til praksis, da de bruger arkitekturen til at træffe IT-

beslutninger ud fra, om de understøtter den generelle forretning. De bruger således alle de

informationer, de er kommet frem til i udarbejdelsen af deres EA til at beslutte, om et projekt

skal igangsættes, eller om der allerede findes funktioner, der dækker de tiltænkte behov.

Modellen kan således betragtes som en styringsmodel.

Udviklingen af en sådan styringsmodel har været en meget langvarig proces, hvor VA har

været tvunget til at træffe hårde beslutninger i en meget politisk organisation. VA har været og

er villige til at tage den langsigtede risiko, en EA-proces er. Resultaterne af en EA er ikke

nødvendigvis tydelige det først lange stykke tid, men formår organisationen at få fuld kontrol

37


over deres nuværende situation, den ønsker fremtidige situation samt, hvordan de får lukket

gap’et mellem disse to tilstande, er der store successer at høste fremover.

5.7. EA-udviklingsindsats

5.7.1. Hvad har de nået fra 2002 til 2003 – eksempler på de væsentligste resultater

• Udarbejdede en One-VA implementeringsplan for året 2002

• Publiserede One-VA Enterprise Architecture version 1.0

• Udarbejdede initielle baselines (”as is”) arkitekturer

• Udarbejdede højt-prioriterede målsætninger for nye (”to be”) arkitekturer

• Udarbejdede en ordnet plan, der adresserede gap (huller) i baselines’ne i forhold til de

ønskelige arkitekturer

• Udarbejdede og implementerede en kommunikationsplan og team

• Udarbejdede IT kapitalinvesteringer- og projektledelsesovervågningsprocesser.

• Forfinede en One-VA EA fortsættende forbedringsproces

• Udarbejdede og ansatte folk til et One-VA EA projektledelseskontor ”Program

Management Office”, der blandt andet inkluderer

o Etablering af et EA-råd, der består af både forretnings- og teknikfolk

Mange af disse aktiviteter er simpelthen nødvendige, for at VA overhovedet kunne gå i gang

med at udarbejde en EA, der har fokus på at optimere forretningsprocesserne. Det viser også

med alt tydelighed, at VA er klar over, hvad det indebærer at starte en EA-proces. De går ikke

tilfældigt i gang med forskellige opgaver, men får etableret nogle strukturer og styringsorganer,

så de kan kontrollere processerne og dermed nå de overordnede mål på en og samme måde.

Det viser med al tydelighed, at VAs EA bliver taget meget seriøst i organisationen.

5.7.2. Planer for år 2003 – eksempler på de væsentligste resultater

• Forbedre den initielle EA for at støtte igangværende og andre berørte projekter, f.eks.

o Revider TRM-modellen og SP

o Derudover er der et par projekter, der skal revideres, der begge relaterer sig til

IT-KEF’en

• Udvide EA-scope’et for året 2005 bugetfremlæggelse, f.eks.:

o Tilføj privacy som et nyt element indenfor IT-KEF’en

38


o Tilføj jobfærdighedsbeskrivelser til EBF’er og KEF’er, der svarer til kolonne 4 i

Zachmans rammeværk, række 1 og 2.

o Definer andre nødvendige områder med henblik på en udvidelse af Zachmans

rammeværk

• Integration af One-VAs EA og projektudarbejdelse inkluderer blandt andet:

o Valider de initielle allokerede funktionelle baselines

o Definer integrationspunkter for dermed at supporter højt-proiriterede projekter.

o Mere præcist definere overholdelsen af One-VAs EA

Ovennævnte viser, at Zachmans rammeværk virkelig ligger til grund for VAs udvikling af

deres EA, og at de udvider efterhånden. De har ikke mappet hele organisationen inde i

rammeværket på én gang, men har forskelligt fokus hvert år. Det første år gik således meget på

at få defineret de strukturer og arbejdsgange, der var nødvendige for overhovedet at kunne

opstarte EA-arbejdet, hvorimod de efterfølgende år går på forbedringer og opdateringer. Der er

således ingen tvivl om, at VAs EA er kommet for at blive.

5.8. VA i forhold til GAO

General Accounting Office (GAO) har en model, hvori de måler de forskellige ministeriers

EA-modenheder8. VA anses som tidligere nævnt som en af de bedste på EA-området, og de

ligger således på niveau 3, som er blandt de bedste 20%. Dog har VA endnu ikke nået målet,

da de, som Ed Meagher også kommenterer tidligere, stadig har mange uløste og komplekse

problemstillinger, der skal løses i forbindelse med at optimere deres forretningsprocesser.

Derudover er de overhovedet ikke begyndt at overveje integration med andre myndigheder,

som de er tæt koblet sammen med i deres daglige arbejde.

Det kan dog ses ud fra GAOs sammenligning af VAs 2001 og 2003 resultater (se bilag 2) samt

GAOs ”Maturity Assesment in 2003” for VA (se bilag 3), at VA bestemt bevæger sig op ad

EA-modenhedsbarometeret, dog udestår der fire GAO-forhold, som VA ikke opfylder. Det er

alle områder, som VA mere eller mindre uden større besvær kunne implementere, f.eks. er et af

de punkter, VA ikke opfylder ”Compliance with EA is measured and reported”. Dette punkt

ville formentlig forholdsvis let kunne opfyldes på baggrund af ovennævnte styringsmodel, hvor

VA allerede kontrollerer, om EA overholdes på en struktureret måde. Ifølge Ed Meagher, er

8 www.gao.gov

39


det naturligvis vigtig for dem at blive rated højt, hvilket er med til at synliggøre deres

imponerende EA-tiltag. Dog er det ikke en model, de lader sig styre af, hvorfor de prioriterer

de områder, som de finder vigtige for deres forretning, og de lader sig dermed ikke dirigere af

GAO-modellen.

GAOs modenhedsmodel svarer meget godt overens med Herzums modenhedsfaser. Begge

modeller har krav om forhold med stor fokus på integration, måling og styring, der skal

opfyldes, for at en organisation bevæger sig op ad modenhedsstigen. GAO er dog noget mere

struktureret og fungerer direkte som en tjekliste, organisationerne blandt andet kan benytte sig

af for at se, hvad de skal igennem for at komme i gang og EA-modnes. Herzums model er mere

teoretisk, hvor han kategoriserer nogle punkter i forskellige definitioner, f.eks. ”Blueprinting”.

En organisation vil sandsynligvis kunne opfylde kriterier fra lidt forskellige faser, dog med

hoveddelen i en af faserne. Begge modeller vil dog være en stor hjælp for organisationer i

deres erkendelse af, hvor lang deres vej er for at få etableret en EA, og modellerne vil

kombineret formentlig være en stor hjælp i opstarten og udarbejdelsen af en EA-proces.

5.9. Afrunding – generel vurdering

VA har udført et stort arbejde i forbindelse med at udvikle deres EA. Baggrunden for at starte

en så stort aktivitet var blandt andet motiveret af en ny lov og et uoverskueligt IT-system, hvis

udbytte var langt fra optimalt. VA var meget bevidste om, at udviklingen af en EA var en

forretningsproces, hvor fokus var på ”veteran-centric” og således ikke drevet af tekniske

ønsker. VA indså, at de ville være nødt til at genopfinde sig selv for at få det størst mulige

udbytte af en EA-process, hvilket kun kunne lade sig gøre, fordi de havde fået opbygget en

solid og effektiv infrastruktur.

VA udarbejder og opdaterer årligt en implementeringsplan, der har fokus på at optimere

forretningsfunktionerne i organisationen. Denne plan er et strategisk dokument, der fungerer

som en slags bibel for alle de mennesker, der beskæftiger sig med VAs EA, idet den fastsætter

retningslinjerne for hvordan, hvornår og hvem der skal udføre hvilket arbejde.

Fremgangsmåden i forbindelse med at udvikle One-VAs EA går gennem seks faser, lige fra

identificering og definering af forretnings- og nøglefunktionerne til at sikre, at nye projekter

stemmer overens med de definerede arkitekturer inklusiv de forretningsmæssige mål. Som en

hjælp til at overskue EA-arbejdet og fremkomme til og styre resultaterne af disse seks faser

benytter VA Zachmans rammeværk.

40


Zachmans rammeværk opfylder ifølge VA de behov, de har til et EA-rammeværk. VA formår

at bruge Zachman i overensstemmelse med deres målsætning om at få deres IT-systemer til at

understøtte deres forretning, hvilket faktisk kan være meget svært for nystartede EA-projekter

især på baggrund af Zachman, da rammeværket ikke definerer processer og metoder i

forbindelse med udfyldelsen af rammeværket. Dette skyldes naturligvis Zachmans direkte

involvering i EA-processen, hviket samtidig viser, at VA var klar over denne udfordring og

valgte at bruge ressource på at imødekomme den. VA har udover et overblik over deres IT

opnået at få udpeget problemer og på den baggrund prioriteret vigtige indsatsområder. De har

således formået at få lukket nogle af hullerne (gap) mellem deres ”as is” og ”to be” situationer.

VA ser ikke ud til at betragte Zachman som et 1. generationsværktøj, da de i henhold til

Herzums egen modenhedsfaser har bevæget sig fra blueprintingfasen og er nu på vej ind i

integrationfasen. De formår således selv at drive rammeværket videre mellem faserne, så det

passer til det niveau, de er på på et givet tidspunkt. VA kunne muligvis også bruge COMS-

rammeværket, som formentlig ville have været en større støtte i prioriteringen af de områder,

VA burde bruge kræfter på, men VA fandt Zachman passende til det, de ønskede sig af et

rammeværk.

Zachman er uden tvivl meget kassefokuseret, og han lægger stor vægt på en meget stringent

struktur, der ender med at give et detaljeret billede af virksomheden ud fra forskellige

perspektiver og aspekter. Dette passer muligvis også meget godt til VA, som er en amerikansk

organisation, idet amerikanere generelt er meget fokuseret og struktureret i deres forsøg på at

opnå deres mål. Desuden ligger det meget naturligt i den amerikanske kultur at være ambitiøs,

hvilket VA bestemt er i deres EA-arbejde, hvor de også har haft de nødvendige ressourcer, der

er uundværlige for at styre og kontrollere en så stor EA-aktivitet samtidig med, at de har

formået at få ledelsen involveret på et nødvendigt plan. VA udfører således EA-arbejdet på et

højt niveau. De har etableret et beslutningsdygtig EA-kontor, hvis hovedfunktion er at sørge

for, at de strategiske mål nåes, og at de satte tidsfrister overholdes. De er hovedansvarlige for

en forsættende udvikling og opdatering af VAs EA. Der er dog endvidere etableret forskellige

teams med forskelligt ansvar, og disse vil blive involveret alt afhængig af området, der søges

belyst.

VA har også fået etableret en styringsmodel, der er en model, som viser et projekts livscyklus

fra der er identificeret et behov, til produktet er i drift. Denne models fornemmeste opgave er at

41


opstille nogle milepæle, hvorunder forskellige forhold skal opfyldes i henhold til de definerede

arkitekturer, for at et projekt kan igangsættes og løbende fortsættes. VA har altså fået deres EA

i drift ved at implementere deres arkitekturer i sådan en model, der danner grundlag for at styre

VAs IT-portefølje mod samme mål. Ifølge Ed Meagher har VAs EA dramatisk ændret den tid,

det taget at håndere og implementere forandringer i organisationen. På baggrund af

ovennævnte styringsmodel, er det således hurtigere at få beslutninger igennem organisationen

end tidligere. Udviklingen af VAs EA er ”the most powerful thing that’s happened in federal

IT in the last 20 years” påpeger Ed Meager, og siger således, at det er en process, der har stor

effekt på på organisationen.

VA ligger højt på GAOs modenhedsmodel, og ville formodentlig uden større besvær kunne

komme endnu højere op. Trods dette, er der stadig mange udfordringer at tage hensyn til i VA i

forbindelse med at få deres IT-portefølje til at understøtte forretningsvision. Derudover er VA

ifølge Ed Meagher overhovedet ikke begyndt at overveje eksternt integration, da dette på

nuværende tidspunkt ville være en al for kompleks proces. USA er et land i krig, hvilket

betyder, at VA som ministerium er tvunget til at være effektive og fremtidsvisionære, da de

politiske krav uden tvivl vil skærpes. Integration med andre ministerier, som er tæt relateret til

VA vil således uden tvivl være et perspektiv, der skal tages højde for i fremtiden, hvorfor VAs

vej til deres ”EA-nirvana” har lange fremtidsudsigter. EA er således en fortsættende aktivitet,

der hele tiden vil indeholde nye mål i relation til den omverden, en organisation befinder sig i.

Nøgleorderne i denne sammenhæng er forbedring, udvidelse og integration.

42


6. Analyse af H:S Hovedstadens Sygehusfællesskab (H:S) består af sygehusene Rigshospitalet, Hvidovre

Hospital, Bispebjerg Hospital, Frederiksberg Hospital, Amager Hospital og Sct. Hans Hospital.

Til samme har de omkring 20.000 ansatte og behandler årligt omkring en ½ million patienter9.

Det kræver store ressourcer at skulle håndtere de mange informationer om ansatte og patienter,

og fokus har før i tiden ofte været på suboptimeringer på de individuelle afdelinger på

hospitalerne. Den nuværende IT-portefølje i H:S består således af en række mere eller mindre

selvstændige systemer eksempelvis Grønt System, der er et patientadministrationssystem, og

en række kliniske systemer, der understøtter forskningsvirksomheden. Disse systemer er ofte

ikke fælles for hele H:S og er ikke optimalt integreret. H:S har derfor valgt at igangsætte et

større IT-projekt, som skal løfte organisationen op på et mere funktionelt og fremtidssikret

niveau på det kliniske område, hvor H:S vil være i stand til at håndtere de forandringer, de står

overfor nu og i fremtiden.

Formålet med at igangsætte ovennævnte IT-projekt er:

At støtte de tværgående kliniske processer, herunder at fremme henholdsvis

sammenhængende patientforløb på tværs af enheder, hospitaler og sektorer i

sundhedsvæsenet

Øge patientsikkerheden

Rationalisere arbejdsgange

Skabe effektiv ressourceanvendelse

Dokumentere høj kvalitet i diagnostik, behandling og pleje

Støtte de kliniske medarbejderes arbejde

Som det tydeligt fremgår af ovenstående, er målsætningen, at både patienter, personale og H:S

som helhed skal få gavn af IT-projektets resultater.

6.1. IT-strategien

H:S’s bestyrelse har vedtaget ”IT-strategi for H:S 2002-2006”, revideret december 2003.

Strategien beskriver, hvordan hospitalerne under H:S vil realisere den kliniske IT-arbejdsplads

på alle hospitaler i H:S inden udgangen af 2006. Personerne bag strategidokumentet er

9 http://www.hosp.dk/direktion.nsf/ResponseDokumenter/25A58FFD2C593890C12566DC004E3ED2

43


hospitalsdirektionerne, IT-chefer, IT-strategiens projektledere og på nogle områder, har

hospitalernes udviklings- og uddannelsesafdelinger også været involveret. Det er helt klart

fornuftigt at inddrage forskellige perspektiver i udarbejdelsen af strategidokumenter for at få

alle perspektiver af et område belyst. IT-faget er repræsenteret gennem IT-cheferne og til dels

også gennem projektlederne, hvor de kliniske områder bliver repræsenteret gennem

hospitalsdirektionerne, der blandt andet består af en lægelig direktør for hvert sygehus i H:S.

Det er også meget positivt, at ledelsen generelt spiller en stor rolle i udarbejdelsen af

strategidokumentet, da de er med til at beslutte, hvordan fremtidens H:S skal se ud samtidig

med, at de er beslutningsdygtige ved de nødvendige valg, der skal træffes. Derudover er

ledelsen med til at tildele de ressourcer, der skal bære et projekt fra start til slut, hvilket er

afgørende for et projekts succes samtidig med, at deres aktive deltagelse er med til at skabe

generel konsensus i organisationen med henblik på at få implementeret og forankret de nye

systemer og ændrede processer så smertefrit som muligt.

I strategidokumentet lægges der først og fremmest vægt på, at IT-strategien skal tage

udgangspunkt i H:S’s overordnede målsætninger, principper, strukturer og opgavefordelinger,

som er formuleret i H:S’s plangrundlag. Disse områder er helt centrale, hvis IT-systemerne

skal understøtte H:S’s overordnede vision. Derudover beskriver strategidokumentet den

nuværende IT-situation (”as is”), dog ikke på et særligt detaljeret teknisk niveau, men der gives

et overordnede billede af de nuværende systemer og deres funktioner. Dokumentet indeholder

også en IT-vision, der beskriver, hvor H:S ønsker at nå hen (”to be”). Dette afsnit er noget

mere udførligt beskrevet end ”as is”-situationen, hvilket viser, at H:S helt klare fokus er på,

hvad de ønsker at nå frem til. Spørgsmål et dog, om H:S er klar over, hvor vigtigt det er at få

kortlagt de eksisterende systemer, funktioner og processer for at kunne opnå den bedst mulige

løsning med de nye systemer, der således bør understøtte det daglige arbejde bedst muligt. Jan

Staack, IT-konsulent i Informatikafdelingen hos H:S Direktionen, nævner imidlertid i en

mail10, at H:S, i hvert fald hvad angår arbejdsgange, foretager en dybdegående undersøgelse.

H:S’s fremgangsmåde i udarbejdelsen af IT-strategien er delt op i forskellige områder. H:S

benævner disse områder ”organisationsudvikling og implementering”, ”faseopdeling og

prioritering” samt en ”handlingsplan”. Det første område tager fat i problematikken omkring at

få organisationen parat til forandring. Det vil kræve tekniske, organisatoriske og menneskelig

10 Se venligst bilag 5

44


forandringer at få gennemført projektet, og det er derfor vigtigt for H:S at ruste organisationen

til at kunne håndtere de forandringer, der bliver resultatet af projektet. Det skal blandt andet

ske ved at uddanne personalet, så de er i stand til at løse de opgaver, de kommer til at stå

overfor. Det andet område omhandler, hvordan H:S vil føre et så stort projekt ud i praksis, som

IT-projektet er. Det er meget omfangsrigt, hvorfor det ikke er muligt, at gennemføre det hele på

en gang. H:S’s pragmatiske løsning på dette er at dele projektet op i tidsbestemte faser, hvilket

får implementeringen til at ske gradvis. Endeligt sluttes af med en handlingsplan, der

indeholder en masterplan, der er struktureret i fem hovedaktiviteter samt en oversigt over

hovedmilepælene igennem hele forløbet fra 2002 til 2006 (bilag 4).

Strategien realiseres gennem projekter og delprojekter ved tæt samarbejde på tværs af H:S,

hvor de benytter en projektmodel, som bruges til at styre IT-strategiens projekter.

Figur 5 - Projektmodellen

Kilde: H:S Direktionen, ”Introduktion til Projektmodellen v.2”

Modellen sætter retningslinjerne for fremgangsmåden i projekter og giver samtidig mulighed

for en ensartede statusredegørelse til ledelsen. Denne model sikre således en fælles

tilgangsvinkel til udarbejdelse af projekter, hvilket er med til at sikre en kontrolleret styring af

projekterne.

45


6.2. H:S og Enterprise Architecture

H:S’s udgangspunkt i deres IT-projekt er at få etableret en klinisk IT-arbejdsplads. Undervejs i

forløbet opstod der dog en formodning om, at H:S havde brug for at få etableret en EA for at

kunne nå de ønskede mål om, at få H:S’s IT-portefølje til at understøtte den overordnede

forretningsstrategi inden for det pågældende område. Denne EA-tankegang skinner svagt

igennem allerede i H:S’s IT-strategi fra starten af år 2002, hvor H:S er bevidste om, at IT-

systemet skal tage et naturligt udgangspunkt i H:S’s plangrundlag samt have de kliniske

processer i fokus. Senere på året i december 2002 udgiver H:S arkitekturdokumentet

”Foranalyse på H:S Portal”, hvor begrebet enterprise architecture nævnes en enkelt gang.

Formålet med dokumentet er gennem modellen ”Business Driven Architecture” (BDA) fra

Meta Group at skabe en oversigt over, hvordan H:S Portalen etableres, således at den kliniske

IT-arbejdsplads kan etableres. Der arbejdes ikke med EA på et synligt niveau i dokumentet,

men der fokuseres dog på overordnet at bruge modellen BDA, der tager et forretningsmæssigt

udgangspunkt. Yderligere er H:S bevidste om, at der eksisterer en ”as is” og en ”to be”

situation, samt at dette vil resultere i et gap, som kortlægger afstanden mellem de to tilstande.

Selvom H:S på dette tidspunkt er bevidste om det forretningsmæssige perspektiv, vælger de

alligevel udelukkende at mønte arkitekturdokumentet på applikationsplatformen. Således

bygger hele dokumentet på tekniske overvejelser, selvom BDA-modellen bevæger sig gennem

tre faser fra det forretningsmæssige fokus og derefter over det tekniske for til sidst at ende ved

planlægningen og gennemførelsen.

Figur 6 – Business Driven Architecture

46


Kilde: H:S Direktionen, ”Foranalyse på H:S Portal”

I slutningen af år 2003 udgiver H:S den seneste revision af IT-strategien. Forskellen mellem de

to udgaver af IT-strategien synes måske ikke umiddelbart så indlysende, men visionernes

indhold kan give en ide om forskellene. I 2001-IT-strategien opstilles fem punkter, der kort

beskriver hovedmålsætningerne, som efterfølgende uddybes, og først i denne uddybning

beskrives det, hvad IT-understøttelsen skal bidrage med. I den nyeste version af IT-strategien

nævnes målsætningen om, at IT skal understøtte forretningen allerede flere gange i visionens

punktopstilling, hvilket må tages som et udtryk for, at H:S tænker mere i et EA-perspektiv i

den seneste udgave af deres IT-strategi.

6.3. H:S i praksis

I vores interview med Jan Staack11, gjorde han opmærksom på, at det tekniske personale i H:S

var kommet med input til en effektivisering af det kliniske område, førend forretningsinputtet

kunne defineres. Grunden til dette skal formodentlig findes i H:S’s måde at håndtere projektet

på. Deres udgangspunkt var den gennemarbejdede IT-strategi, som definerer, hvad det er, H:S

vil nå, og de tager således i strategien et forretningsmæssigt udgangspunkt, men i praksis bliver

fokus meget hurtigt et IT-projekt. Følges Zachmans rammeværk, ville H:S skulle gennemgå i

alt seks perspektiver for at kunne få kortlagt organisationen med henblik på at understøtte den

generelle forretning. Umiddelbart virker det som om, H:S springer direkte fra ”planner”

perspektivet til ”designer/builder” perspektivet. Dette på trods af, at H:S har en veldefineret

strategi og faktisk også umiddelbart arbejder med modellen BDA i deres dokument

”Foranalyse på H:S Portal”, som tidligere nævnt foruden de tekniske aspekter også

indeholder tydelige forretningsaspekter.

En forklaring på H:S’s måde at gribe deres EA an på kan være, at det politisk ikke umiddelbart

er muligt i organisationen at gennemføre en så omfangsrig, ressourcekrævende og langsigtet

risikofyldt aktivitet, som en EA er. Som tidligere nævnt er det utrolig vigtigt at opnå

topledelsens opbakning for at kunne gennemføre en EA, som er mere eller mindre alt

omfagrende i en organisation. Hvis dette ikke har været muligt for projektgruppen i

Informatikafdelingen hos H:S Direktion, vil det være meget svært at gennemføre. For at få

11 Mandag d. 10. maj 2004

47


konsensus i deres nuværende ønske om at få startet en EA-proces, er de muligvis nødt til at

starte i de små med de midler, de har til rådighed og så håbe på, at topledelsen med tiden

kommer til den erkendelse, at EA er en nødvendighed og således ikke er én afdelingsproces,

men en tværfaglig aktivitet, der kræver involvering af beslutningsdygtige tekniske og

forretningsmæssige folk på tværs af organisationen. Dette viser således, at der ingen garantier

er for, at teoriens til tider ideelle verden umiddelbart kan spejles i den virkelig verden. En

anden mulighed kunne dog også være, at H:S ikke helt har forstået omfanget af en EA, hvor

essensen er, at de forretningsmæssige visioner danner grundlag for de valgte IT-systemer, hvor

målet er, at få en organisations IT-portefølje til at understøtte forretningen. Dog skal det i

denne forbindelse nævnes, at H:S faktisk er bevidste om, at de ønsker patienterne og borgerne i

fokus, og det således er deres overordnede mål, som skal danne grundlag for en effektivisering

af det kliniske område, der imidlertid i praksis har et meget teknisk fokus. Denne

effektivisering startede således også som et IT-projekt, der så siden hen har udmøntet sig i et

ønske om at gennemføre en EA-proces, hvilket også kan være årsagen til, at EA kommer ind

lidt fra siden af og ikke på nuværende tidspunkt bliver så struktureret håndteret.

Det er imidlertid utrolig vigtigt, at H:S er klar over, hvad en EA indebærer og dermed er fuldt

ud opmærksom på konsekvensen af de valg, de træffer. Ved at foretage bevidste eller tvungne

fravalg i forbindelse med udarbejdelsen af en EA, vil en organisation være langt bedre rustet til

at modstå de problemer, der kommer undervejs i modsætning til, hvis de kommer som

overraskelser. En EA kræver, at der tages udgangspunkt i hele forretningen, ellers kan det

resultere i suboptimeringer i de enkelte afdelinger, hvor der etableres servicesiloer. Fokus bør

være på en tværgående integration af informationssystemerne, der har som mål at effektivisere

forretningen og dermed opnå en bedre service til kunderne. H:S skal således være opmærksom

på, at en EA skal være forretningsdrevet og ikke teknikdrevet. Er dette ikke klart, kan de let

mislykkes i deres vision om, at deres teknik skal understøtte de overordnede mål og ikke

omvendt.

H:S har ikke brugt et rammeværk for at få defineret en EA, men har brugt en model til at guide

”arbejdsworkflow’et” til at belyse, hvordan deres portal skal etableres. Til dette formål har

BDA være anvendelig, da den giver et overblik over, hvilke processer en organisation skal

igennem for at kunne implementere et integreret IT-system, der understøtter forretningen.

Dette forklarer umiddelbart valget af BDA frem for f.eks. et rammeværk som Zachmans.

Zachman definerer ikke som sådan rækkefølgen af organisationens arbejdsprocesser, men

48


forsøger mere at definere de perspektiver og aspekter, der er nødvendige for at få etableret en

EA. Zachmans rammeværk udstikker således ikke en kogebog over, hvordan et IT-system kan

etableres, men er i stedet en hjælp til at få kortlagt en organisations ”as is” og ”to be”

situationer, hvor rammeværket gør det lettere for en organisation at udpege de problemer, de

måtte have, samt de gap’er, der således eksisterer, og som skal lukkes. Zachmans rammeværk

hjælper således ikke i prioriteringen af problemerne ud fra den betragtning, at det er op til den

enkelte organisation og dennes fokus og ønsker. Det er således tydeligt, at H:S ikke har været

100% EA-bevidste, siden de har valgt ikke at benytte et rammeværk fuldt ud. Havde de f.eks.

brugt BDA-modellen eller Zachmans rammeværk til fulde, ville de have været tvunget til at

vurdere deres kliniske funktioner ud fra flere perspektiver.

For i fremtiden bedre at kunne varetage deres situation ud fra et EA-perspektiv er H:S i gang

med at etablere et EA-kontor, hvor en chefarkitekt skal koordinere EA-arbejdet i H:S. Dette må

forventes at føre til en langt mere kritisk holdning overfor EA og forskellige rammeværker. De

vil formodentlig langt bedre være i stand til at vurdere, hvilken type rammeværk en

organisation som H:S har brug for. Zachmans rammeværk kan eventuelt stadig virke for

kompleks for H:S, da de formodentlig i stedet vil have bruge for et rammeværk, der kan hjælpe

dem igennem processerne. I den forbindelse er det dog værd at nævne, at det ikke er vores

opfattelse, at Herzums definition af 1. og 2. generationsrammeværker nødvendigvis er helt

korrekt. Det er i stedet den enkelte organisations ønsker og behov, der skal være bestemmende

for, hvilket rammeværktøj, der vælges. Dog er Herzums modenhedsfaser meget relevante i en

organisations erkendelse af, hvor langt de er i forhold til et EA-arbejde, da en sådan erkendelse

vil være en stor hjælp i forbindelse med, at organisationen får en fornemmelse af, hvor

omfangsrig en EA-proces er, og hvor mange ressourcer, de er nødt til at benytte i udarbejdelsen

af en sådan aktivitet. En EA-proces kræver således også, at organisationen er villig til at tage

en vis risiko, da EA er en meget lang aktivitet, hvor der går nogen tid, inden egentlige

økonomiske resultater fremkommer, men hvor der kræves store initielle investeringer. Derfor

kan det være fornuftigt, hvis organisationen starter med at satse på meget kritiske områder, der

vil forbedre sammenkoblingen af IT og forretningen markant. På den måde vil de hurtigt få

genereret synlige resultater, så EA kan få forankret dens nødvendige eksistens i hele

organisationen og ikke mindst hos topledelsen i H:S’s tilfælde.

49


6.4. Afrunding - H:S og VA

Der er stor forskel på H:S og VAs erkendelse af, at en styring af deres IT-portefølje er en

nødvendighed for fremtiden. VA blev blandt andet ved lov12 motiveret til at gå EA vejen, og

har været meget grundige og struktureret i deres EA-arbejde. De har således fulgt Zachmans

rammeværk stringent og være i stand til at styre processerne effektivt ikke mindst på grund af,

at de faktisk hyrede Zachman og dermed inkluderede ham i processen. VA er desuden meget

opmærksomme på, at EA en evig forretningsdrevet proces, hvor teknikkens eneste formål er at

styrke deres forretning, hvor kunden er i centrum. H:S er endnu i etableringsfasen af deres EA,

da de i udførelsen af deres IT-projekt er kommet til en forståelse af, at det vil være fornuftigt at

få etableret en EA, eftersom dette formentlig vil være svaret på en bedre styring af deres IT-

portefølje i fremtiden, der mere effektivt ville kunne håndtere forandringer med det formål at

understøtte den overordnede forretning.

En af årsagerne til, at VA er betydelig længere fremme i deres EA-udvikling end H:S, er uden

tvivl den politiske beslutning, der ligger bag ovennævnte lov, som pålægger statslige

amerikanske organer at kontrollere deres IT blandt andet ved etableringen af en ITA

(”Information Technology Architecture”), som var startskuddet for EA i VA. Derudover er det

også værd at overveje de kulturelle forskelligheder, der findes organisationerne imellem, når de

sammenlignes. H:S er en organisation bestående af mange klinikere. Klinikere vælger ofte at

koncentrere sig om deres ”håndværk” og lade sekretærer og IT-afdelingen om den daglige

håndtering af alt, der involverer IT. I en sådan kultur kan det være svært at etablere et

samarbejde mellem forretningsenhederne og IT-afdelingen, da klinikerne har svært ved at

overskue de muligheder, der ligger i anvendelsen af IT og dermed ofte finder det forstyrrende

at blive involveret i forbindelse med udvikling af IT, selvom formålet er at forbedre deres og

deres ”kunders” hverdag. Det betyder, at H:S temmelig sikkert vil møde utrolig stor modstand

mod de forandringer, nye IT-systemer vil bringe med sig, hvilket således kræver særligt

opmærksomhed og ressourcer. En organisation som VA, der er langt mere administrativ,

anvender i langt højere grad IT som et redskab i det daglige arbejde, f.eks. til administration af

veteraner, og de har således en helt anden kultur, hvor de er vant til at håndtere IT. De vil

således have lettere ved at implementere en EA på grund af en lettere forståelse af fordelene og

tillid til det, som en forandring vil bringe. Dog undgår VA bestemt heller ikke politiske

slagsmål og modstand, men da EA foregår som en top-down proces hos denne myndighed,

12 Clinger-Cohen Act

50


hvor ministeren direkte er involveret, er det umiddelbart lettere at få forandringer tvunget

igennem i forhold til H:S, som bringer EA på banen i et mere buttom-up perspektiv, i hvert fald

i forhold til VA, hvor Informatikafdelingen sidder som de EA ansvarlige på nuværende

tidspunkt.

VA har indført deres EA helt efter bogen blandt andet på baggrund af deres brug af Zachman.

Dette kunne således kun lade sig gøre på grund af den solide og effektive infrastruktur, VA

havde fået opbygget årene forinden. Et af resultaterne af VAs EA er en projektmodel, der er

integreret med deres EA. Modellen er således en styringsmodel i forbindelse med at beslutte,

om nye produkter skal sættes i gang. VA har således også allerede set synlige resultater af

deres EA i forbindelse med godkendelse af deres IT-investeringer, som i dag går langt

hurtigere igennem end tidligere. H:S er som sagt stadig i EA-etableringsfasen, men benytter

dog også en projektmodel. Denne model er derimod endnu ikke så langt, idet dens fokus er på

udarbejdelsen af det faktiske projekt og ikke involvere bestemmelser om, hvorvidt et projekt

skal sættes i gang. Modellen er bestemt stadig meget relevant og kan uden tvivl ses som en

model, der med tiden vil blive udbygget til også at indeholde kriterier i forhold til, om H:S’s

fremtidige arkitekturer er overholdt. H:S skal dog være klar over, at EA er en langsigtet

risikofyldt proces, de er tvunget til at tage, hvis de ønsker at se, de markante resultater en

veletableret EA kan bringe med sig.

Modenhedsmæssigt har VA bevæget sig fra Herzums blueprintingfase og er nu godt på vej ind

i integrationsfasen. De har fået etableret en styringsmodel og har således fået operationaliseret

deres arkitekturer. H:S har ikke arbejdet med EA i lige så lang tid som VA og må betragtes

som værende i inceptionfasen på vej mod klassifikationsfasen. De har stor fokus på teknik,

men mangler stadig nogen sammenhæng mellem forretningsstrategien og IT-strategien i hver

fald i praksis. De er stadig i EA-etableringsfasen, hvor de forsøger at opbygge en formel EA-

organisation, hvilket er et tegn på, at der vil ske mange interessante ændringer inden for den

næste årrække, hvis de fortsætter med at modnes.

Sammenlignes H:S og VA på baggrund af VAs GAO-rapport, vil det ligeledes tydeligt fremgå,

at VA er længere fremme i deres EA-udvikling end H:S (se bilag 2 og 3). Dog skal det

bemærkes, at H:S i øjeblikket er ved tage EA-initiativer med det formål at optimerer deres

forretningsprocesser herunder de understøttende IT-systemer indenfor det kliniske område, så

H:S er bestemt på vej fremad. Her skal H:S dog være opmærksomme på, at den hastige

51


fremgang kan skyldes, at de ikke har arbejdet i dybden i de indledende faser, som VA

eksempelvis gjorde med deres infrastruktur. Faren ved dette kan være, at H:S ikke opnår de

tværgående processer, der egentlig er formålet med EA, men igen skaber en silo-struktur.

Herzum og GAO-modenhedsmodellerne fungerer som tidligere nævnt fint sammen, selvom de

har hver deres opbygning. Begge modeller kategoriserer en organisation, så det er let at aflæse,

på hvilket EA-niveau en organisation befinder sig, samt hvor lang vej der er, før den når det

stadie, Herzum kalder nirvana. I VAs tilfælde er der faktisk ikke langt til, at toppen i GAO er

nået, hvilket giver anledning til en diskussion om, om der findes et endeligt mål, eller om der

ikke altid vil være mere at opnå i en verden, der konstant forandrer sig og stiller nye krav til

organisationerne. EA karakteriseres som en iterativ proces, hvilket betyder, at det vil være

svært, nærmest umuligt at nå det fuldkomne. I så falde burde modenhedsmodellerne jævnligt

revideres for hele tiden at følge udviklingen og være et skridt foran de organisationer, der skal

vurderes.

52


7. Perspektivering Der er ingen tvivl om, at flere organisationer bør overveje at sætte fokus på at få opbygget en

EA, der kan hjælpe med at styre deres IT-portefølje mod organisationens overordnede

forretningsmål. Det er en ressourcekrævende proces, der stiller store krav til forandrings- og

risikovillighed i en organisation, hvorfor det er helt centralt at diskutere, hvordan en

organisation skal nå konsensus hos topledelsen for at få sat EA i gang med det bedste

udgangspunkt.

Det ville ikke være optimalt at fremlægge EA-planerne på baggrund af Zachmans rammeværk.

Dette ville være alt for kompleks og abstrakt for topledelsen at håndtere, og det kan

sammenlignes med, hvis ingeniørernes detaljerede planer for Storebæltsbroen var brugt som

beslutningsgrundlag i folketinget for at få vedtaget igangsættelsen af brobyggeriet. Den bedste

fremgangsmåde vil formentlig være at fremvise tal over, hvor mange ressourcer der bliver

brugt på teknik, der egentlig ikke understøtter forretningen, inklusiv eksempler på systemer,

der overlapper hinanden uden at skabe værdi. Ledelsen skal komme frem til en forståelse af, at

organisationen skal vendes på hovedet, så alt kommer frem i lyset med det formål at få fuldt ud

kontrol over organisationens ”as is” situation, som efterfølgende danner baggrund for at nå de

nye mål, som vil medføre positive resultater for forretningen.

Ovennævnte er uden tvivl et område, H:S skal være opmærksom på, hvis de ønsker at gå linen

ud med EA. Det er vigtigt, at opbakningen til de ansatte, der beskæftiger sig med EA, kommer

fra direktionen i H:S, således at EA kommer til at foregå på tværs af organisationen. Vores

indtryk er, at det i øjeblikket hovedsageligt er Informatikafdelingen, der arbejder med EA hos

H:S, som formentlig vil have tendens til at give arbejdet et overordnet teknisk perspektiv. Er

det muligt at få dannet et team af flere beslutningsdygtige folk med forskellige

fagkompetencer, ville dette uden tvivl bidrage til, at EA får den opmærksomhed på tværs af

organisationen, der er nødvendig for at opnå det mest optimale udgangspunkt for en EA-

proces. VA var således meget bevidste om at få dannet et beslutningsdygtig EA-team, hvor der

blev stillet store krav til dem både fagligt med også med hensyn til deres arbejdsindsats. Det

var ikke tilladt for medlemmerne at sende suppleanter i deres sted, og hvor det i starten ikke

var så attraktivt at være et EA-teammedlem, er der i dag stor konkurrence om at være

involveret, da det er her mange af de vigtige beslutninger træffes.

53


Yderligere skal H:S være klar over, at EA er en forretningsdrevet proces, hvor IT ikke er det

styrende element. Dog ville det være ufuldstændigt at tro, at forretningsmålene kan opnås uden

hensyntagen til IT. Der er trods store fremskridt inden for IT stadig begrænsninger, som en

virksomhed til tider vil være tvunget til at tage hensyn til, og den vil dermed være begrænset af

disse. Alligevel er det vigtigt, at H:S ikke lader sig styre af, at deres udgangspunkt var et IT-

projekt i deres etablering af en EA, og således ikke forfalder til at lade teknikken styre, nu hvor

Informatikafdelingen sidder med ansvaret for udviklingen af deres EA.

H:S er dog på vej frem og de er bestemt lang mere EA-parate end mange andre danske

virksomheder. Er H:S bevidste om ovennævnte forhold, er der ingen tvivl om, at de vil modnes

i takt med, at der kommer større fokus på deres EA-arbejde. H:S har muligvis også mange

politiske forhold at kæmpe med. Der er bestemt kulturelle forskelle mellem H:S og VA, der

påvirker deres forskellige håndteringer af EA. VA’s EA-proces var trods alt drevet af en lov,

der tvang dem til at gå i den retning, hvis de ønskede at få deres budgetter godkendt. Dette er et

ret tydeligt incitament for at sætte det helt store EA-arbejde i gang. Selvom vi kunne ønske, at

EA-teamet i H:S forsøgte mere aktivt at nå ud til hele ledelsen og måske endda endnu højere

(politikere), er dette naturligvis meget svært og måske endda umuligt. H:S er trods alt en

offentlig institution, hvor tingene alt andet lige tager længere tid at få igennem, og hvor det kan

være svært at nå ud til topledelsen i forhold til private virksomheder, som f.eks. AP Møller.

Her ville det umiddelbart være lettere at få en EA-proces igennem med ledelsens fulde

opbakning, hvis de ellers professionelt blev præsenteret for mulighederne i en EA og var enige

i de bidrag, en sådan proces kan tilvejebringe.

I diskussionen omkring modenhed, er vi inde på, at det endelige nirvana aldrig kan nås. Det er

muligt at nå den højeste rating på GAOs modenhedsmodel og nå Herzums optimeringsfase,

som de ser ud i dag. Men der er ingen tvivl om, at disse topfaser vil ændre sig. Det, der

betegnes som det fuldendte i dag, vil se anderledes ud i morgen. VA ligger nummer 3 på GAOs

ratingliste og mangler ikke at opfylde mange forhold for at nå til tops, dog har de overhovedet

ikke overvejet ekstern EA-integration med de ministerier, de arbejder tæt sammen med, da

dette på nuværende tidspunkt ville være alt for kompleks både for organisationen men også for

selve systemerne. Det er således vores helt klare opfattelse, at kravene til en virksomhed, for at

den befinder sig i et EA-nirvana, vil ændre sig i takt med tiden.

54


EA er et forholdsvis nyt begreb i Danmark. Ser vi på modellen nedenfor, der viser Gartner

Groups kurve over introduktion af ny teknologi/begreber, i forhold til EA i Danmark, ville den

vise, at Danmark først lige er startet og således er på vej op mod ”peak of inflated

expectaions”.

Firgur 7 – Hype Cycle of New Info Technologies

EA i DK

Kilde: www.rairlington.com/hypecyc.html

Der er således mange interessante år at se frem til, hvor EA uden tvivl vil komme mere og

mere i fokus både indenfor private og offentlige organisationer. Det kræver dog, at der bliver

arbejdet hårdt i perioden efter ”disillusionment”, da tiden efter denne periode kræver et langt

sejt træk, men resultatet må tilgengæld forventes at blive et langt mere stabilt og fremtidssikret

fundament for EA, end det vi kender i dag.

55


8. Konklusion Formålet med at udarbejde en EA er at støtte en organisations vision gennem dennes IT.

Behovet for at benytte EA til at sætte fokus på organisationers IT-portefølje er således aktuelt

nu som aldrig før, da dette vil hjælpe med at styre det IT-kaos, der ofte eksisterer i en

organisations IT-portefølje. Det er i den forbindelse vigtigt, at organisationerne er klar over,

hvad EA indebærer, inden de begiver sig ud på EA-rejsen. Organisationen skal være villig til at

tage den risiko, der er forbundet med et så stort og langsigtet projekt og være indstillet på, at

der vil komme mange forandringer.

I udarbejdelsen af en EA er det vigtigt, at fokus er på, at EA er en forretningsorienteret proces,

hvor teknikken blot skal understøttte den overordnede forretningsvision. Et EA-team bør dog

bestå af både teknik- og forretningsfolk på tværs af organisationen, da det giver de bedste

muligheder for at integrere de to områder samtidig med, at teamet skal have den nødvendige

magt til at træffe de beslutninger, der følger med en EA-proces. EA er en evig aktivitet, der

definerer arkitekturdokumenter, som skal bruges i fremtidige beslutninger i relation til at styre

en virksomheds IT mod de overordnede forretningsmål. Lykkes dette, vil resultatet være en

agil IT-portefølje, der er klar og moden til at håndtere de forandringer, der uundgåeligt vil

komme i fremtiden.

En effektiv EA kræver, at organisationen arbejder målrettet for at udarbejde de arkitekturer, der

passer præcist til dens behov. Zachman giver med sit rammeværk et bud på, hvordan en

organisation kortlægges ud fra forskellige perspektiver og aspekter, hvilket hjælper

organisationen med at definere de problemområder, der eksisterer i organisationen. Zachmans

rammeværk er metode og procesuafhængigt. Det betyder, at det er op til den enkelte

organisation at anvende rammeværket på den måde, som passer bedst til dens behov og ønsker.

Det er en stor fordel at kunne tilpasse brugen af rammeværket udfra en organisations situation,

men samtidig kan det medvirke til, at rammeværket virker meget uoverskueligt og kompleks

for mange organisationer. Herzum introducerer således sin egen komponentbaseret model, og

påpeger, at denne indeholder processer og særdeles gode skalleringsmuligheder og dermed

bedre sikrer den fremtidige brug.

VA er en af de organisationer, der har taget EA til sig og som i dag arbejder seriøst med

området. Inden de startede med at udarbejde en EA i forbindelse med forretningsfunktionerne,

56


brugte de tre år på at optimere deres infrastruktur, hvilket har givet dem det nødvendige

grundlag for det efterfølgende EA-arbejde. Resultatet er, at VA i dag fremstår som et

skoleeksempel på, hvordan en EA-proces kan fungere og anvendes. H:S er indenfor de sidste

par år også begyndt at arbejde seriøst med EA, men er dog ikke så langt som VA. De er i

øjeblikket ved at etablere et EA-kontor, der skal styrke det fremtidige EA-arbejde i

organisationen. Dog bærer arbejdet stadig præg af at udspringe fra et IT-projekt, og det er også

vores umiddelbare opfattelse, at tankerne omkring vigtigheden af en EA-proces ikke deles helt

op i direktionen. Ledelsens opbakning er central for at opnå konsensus i hele organisationen i

forbindelse med et EA-projekt. Dette er dog ikke til hinder for, at H:S med tiden kan få

udarbejdet en gennemført EA, da hele arbejdet er en lang proces, hvor organisationen må

formodes løbende at modnes og udvikles.

Vurderes organisationernes EA-modenhed vil det kunne ses, hvor langt de er nået. VA er nået

rigtig langt og vil formentlig inden længe toppe GAOs modenhedsmodel ud fra de krav, denne

model indeholder på nuværende tidspunkt. Verden forandres dog mærkbart, hvilket betyder, at

der hele tiden vil være nye forhold, som kan gøres bedre. Begge organistioner står således

overfor nogle meget spændende år, hvor mange nye EA-udfordringer skal løses i den uendelige

EA-proces.

57


9. Litteraturliste

Bøger

“Hvidbog om IT-arkitektur”, Udgivet af Ministeriet for Videnskab, Teknologi og Udvikling,

2003

O’Rourke, Carol, Neal Fishman & Warren Selkow, ”Enterprise Architecture, Using The

Zachman Frameworke”, Thompson Course Technology, 2003

Artikler

“IT-strategi for H:S 2002-2006, Revideret December 2003”, Udgivet af Hovedstaden

Sygehusfællesskab, december 2003

“IT-strategi for H:S 2002-2006”, Udgivet af Hovedstaden Sygehusfællesskab, marts 2002

“One-VA Enterprise Architecture Implementation Plan: FY 2002”, Udgivet af Department of

Veterans Affairs, 2002

“One-VA Enterprise Architecture Implementation Plan: FY 2003”, Udgivet af Department of

Veterans Affairs, 6. februar 2003

”Enterprise Architecture: Strategy, Governance & Implementation”, Udgivet af Department of

Veterans Affairs (USA), August 2001

Herzum, Peter, “Applying Enterprise Architecture”, Enterprise Architecture Vol. 6, No. 3,

Cutter Consortium

Sowa, John & John Zachman, “Extending and formalizing the framework for information

systems architecture”, IBM Systems Journal, Vol. 31, NO 3, 1992

Zachman, John, “A framework for information systems architecture”, IBM Systems Journal,

Vol. 28, NO 3, 1987, 1999

58


Hjemmesider

http:// www.rairlington.com/hypecyc.html

http://cio.ost.dot.gov/architecture/

http://www.enterprise-

architecture.info/Images/Defence%20C4ISR/Enterprise%20Architecture%20Defense.htm

http://www.fcw.com/fcw/articles/2003/1110/web-va-11-10-03.asp

http://www.fcw.com/fcw/articles/2003/1201/web-va-12-02-03.asp

http://www.fedsources.com/events/download/meagher.pdf

http://www.gao.gov

http://www.gao.gov/new.items/d0440.pdf

http://www.gcn.com/vol1_no1/enterprise-architecture/23663-1.html

http://www.hosp.dk

http://www.hosp.dk/direktion.nsf/ResponseDokumenter/25A58FFD2C593890C12566DC004E

3ED2

http://www.nbnn.com/20_34/manager/17598-1.html

http://www.va.gov

http://www.va.gov/oirm/architecture/default.asp

http://www.va.gov/oirm/CIO/itstrat.pdf

http://www.va.gov/OIT/CIO/Default.asp

http://www.va.gov/OIT/EAM/default.asp

http://www.va.gov/opp/sps/2003plan/enable.pdf

http://www.va.gov/opp/sps/2003plan/goal1.pdf




http://www.zifa.com

http://www1.va.gov/opa/bios/index.cfm

http://wwwoirm.nih.gov/itmra/itmra96.html

Interviews

Interview af Jan Staack, IT-konsulent hos H:S Direktionen

Interview af Per Strand, IT-konsulent

Telefoninterview af Ed Meagher, VA Chief Information Officers (CIO) Council

59


Bilag 1 Zachmans rammeværk

60


Bilag 2 Table 59: Comparison of Maturity Assessments in 2001 and 2003 (According to Framework Version 1.0): Department of Veterans Affairs

Satisfied? Stage

Element 2001 results 2003 results

Stage 1: Creating EA awareness

Agency is aware of EA.

Yes Yes

Committee or group representing the enterprise is responsible for directing, overseeing, and/or approving EA.

Yes Yes

Program office responsible for EA development exists.

No Yes

Chief architect exists. No Yes

EA being developed using a framework and automated tool.

Yes Yes

EA plans call for describing enterprise in terms of business, data, applications, or technology.

Yes Yes

Stage 2: Building the EA management foundation

EA plans call for describing “as is” environment, “to be” environment, or sequencing plan.

Yes Yes

Written/approved policy exists for EA development. No Yes

EA products are under configuration management. Yes Yes

EA products describe or will describe enterprise’s business—and the data, applications, and technology that support it.

Yes Yes

EA products describe or will describe “as is” environment, “to be” environment, and sequencing plan.

Yes Yes

Stage 3: Developing architecture products

EA scope is enterprise-focused. Yes Yes

Written/approved policy exists for information technology investment compliance with EA.

Yes Yes

EA products describe enterprise’s business—and the data, applications, and technology that support it.

No No

EA products describe “as is” environment, “to be” environment, and sequencing plan.

No No

Stage 4: Completing architecture Products

Agency chief information officer has approved EA.

Yes Yes

Written/approved policy exists for EA maintenance. No Yes

Either EA steering committee, investment review board, or agency head has approved EA.

No Yes

Stage 5: Leveraging the EA for managing change

Metrics exist for measuring EA benefits.

Yes Yes

Overall maturity stage Stage 1

Stage 3

61


Bilag 3 Table 60: Maturity Assessment in 2003 (According to Framework Version 1.1): Department of Veterans Affairs Stage 1: Creating EA awareness

Yes

Adequate resources exist. Yes Committee or group representing the enterprise is responsible for directing, overseeing, or approving EA.

Yes

Program office responsible for EA development and maintenance exists.

Yes

Chief architect exists. Yes EA is being developed using a framework, methodology, and automated tool.

Yes

EA plans call for describing both “as-is” and “to-be” environments of the enterprise, as well as a sequencing plan for transitioning from the “as-is” to the “to-be.”

Yes

EA plans call for describing both “as-is” and “to-be” environments in terms of business, performance, information/data, application/service, and technology.

Yes

EA plans call for business, performance, information/data, application/service, and technology descriptions to address security.

Yes

Stage 2: Building the EA management foundation

EA plans call for developing metrics for measuring EA progress, quality, compliance, and return on investment.

Yes

Written and approved organization policy exists for EA development.

Yes

EA products are under configuration management. Yes EA products describe or will describe both “as-is” and “to-be” environments, as well as a sequencing plan.

Yes

Both “as-is” and “to-be” environments are described or will be described in terms given in Stage 2.

Yes

These descriptions address or will address security. Yes

Stage 3: Developing architecture products

Progress against EA plans is measured and reported. Yes Written and approved organization policy exists for EA maintenance.

Yes

EA products and management processes undergo independent verification and validation.

No

EA products describe both “as-is” and “to-be” environments, as well as a sequencing plan.

Yes

Both “as-is” and “to-be” environments are described in terms given in Stage 2.

No

These descriptions address security. Yes Organization CIO has approved current version of EA. Yes Committee or group representing the enterprise or the investment review board has approved current version of EA.

Yes

Stage 4: Completing architecture products

Quality of EA products is measured and reported. No Written and approved organization policy exists for IT investment compliance with EA.

Yes

Process exists to formally manage EA change. Yes EA is integral component of IT investment management process. Yes EA products are periodically updated. Yes IT investments comply with EA. Yes Organization head has approved current version of EA. Yes Return on EA investment is measured and reported. Yes

Stage 5: Leveraging the EA for managing change

Compliance with EA is measured and reported. No

62


Bilag 4 Hovedmilepæle i perioden 2002-2006

63


64

Bilag 5 Mail fra Jan Staack, mandag d. 17. maj 2004 Hej Vibeke og Charlotte Ja, udarbejdelsen af krav til kliniske funktioner, er sket parallelt i projektet om Klinisk Proces, hvor der er foretaget arbejdsgangsanalyser af eksisterende arbejdsgange, og efterfølgende opstillet 55 use cases til udbuddet for klinisk proces. Vi har sammen med IOCORE (som er et firma i Holte som arbejder med arkitektur og design) gennemgået use casene for at identificere om der er overlappende ønsker til funktionalitet, og se om vi har kunnet gruppere funktionalitet, som kan defineres som fælles kliniske komponenter, på tværs af use cases. (See attached file: Arkitekturbeskrivelse kliniske komponenter.ppt) Med venlig hilsen Jan Staack H:S Direktionen - Informatikafdelingen Bredgade 34 - 1260 København K Tlf +45 33 48 37 68 - Fax +45 3348 3807 e-mail: mailto:[email protected] - www.hosp.dk

Enterprise Architecture - inkl. rammerværker - i teori …W3-projekt – Enterprise Architecture,...

Documents

Transcript of Enterprise Architecture - inkl. rammerværker - i teori …W3-projekt – Enterprise Architecture,...