Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
• 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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
• 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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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.va.gov/opp/sps/2003plan/goal2.pdf
http://www.va.gov/opp/sps/2003plan/goal3.pdf
http://www.va.gov/opp/sps/2003plan/goal4.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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
Bilag 1 Zachmans rammeværk
60
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
Bilag 4 Hovedmilepæle i perioden 2002-2006
63
W3-projekt – Enterprise Architecture, inkl. rammeværker – i teori og praksis Charlotte Cleemann Vibeke Eriksen Forår 2004
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