Som C-level leder er der en stor chance for at man på et tidspunkt skal tager stilling til om et BPM, SOA og/eller EA program skal iværksættes. Spørgsmålet ”Hvad er egentlig risici med dette initiativ?” skal stilles og risiciene skal håndteres, dvs. at der skal iværksættes aktiviteter, som reducerer risikoens sandsynlighed eller som afbøder dens potentielle konsekvenser. Uden at påvise det matematisk, kan man gå ud fra at risikoen ikke bliver mindre, når initiativet kombinerer flere komplekse discipliner som EA, SOA og BPM. Dette kræver at man ændrer noget afgørende ved årsagerne til de problemer, man potentielt kan opleve med de enkelte discipliner. Når man starter et EA initiativ skal man være klar over at: Failure is an option!

1. Failure is an option …
Eller: Hvorfor fejler Enterprise Arkitektur initiativer?
MINIPROJEKT – ENTERPRISE ARCHITECTURE
ITU KØBENHAVN – F2011
UNDERVISERE: JOHN GØTZE, SØREN ALAIN MORTENSEN
18. maj 2011
Claus Kortenkamp
010265
ckor@itu.dk

2. Failure is an option …
Eller: Hvorfor fejler Enterprise Arkitektur initiativer?
Indhold
1 INDLEDNING ............................................................................................................ 2
1.1 PROBLEMFORMULERING........................................................................................ 3
1.2 METODE .......................................................................................................... 3
1.3 AFGRÆNSNING ................................................................................................... 3
2 BEGREBSAFKLARING ................................................................................................... 4
2.1 ENTERPRISE ARKITEKTUR ...................................................................................... 4
2.2 ELEMENTER AF EN ENTERPRISE ARKITEKTUR ............................................................... 5
2.2.1 EA TILGANG, METODE OG RAMMEVÆRK .............................................................. 5
2.2.2 EA ARTEFAKTER, REPOSITORY OG GOVERNANCE ................................................... 5
2.2.3 EA BEST PRACTICES ....................................................................................... 5
3 TEORI .................................................................................................................... 6
3.1 BERNARD EA3 ................................................................................................... 6
3.2 TOGAF 9 ......................................................................................................... 6
3.3 OIO EA ........................................................................................................... 6
3.3.1 OIO EA METODE ......................................................................................... 6
3.4 FORANDRINGSLEDELSE ......................................................................................... 7
4 ANALYSE ................................................................................................................. 8
4.1 EA PROBLEMER I PRAKSIS ....................................................................................... 8
4.1.1 GARTNER .................................................................................................. 8
4.1.2 IDS SCHEER................................................................................................ 9
4.1.3 ANALYSE AF EA PROBLEMER I PRAKSIS ............................................................... 10
4.2 EA METODERNES HÅNDTERING AF RISICI I EA INITIATIVER .............................................. 11
4.2.1 BERNARD EA3 .......................................................................................... 11
4.2.2 TOGAF ADM .......................................................................................... 15
4.2.3 OIO ...................................................................................................... 19
4.3 RESULTATER ................................................................................................... 24
4.3.1 EA3 ....................................................................................................... 24
4.3.2 TOGAF ADM .......................................................................................... 24
4.3.3 OIO EA .................................................................................................. 24
5 KONKLUSION ......................................................................................................... 25
6 PERSPEKTIVERING OG METODEKRITIK ............................................................................ 25
7 BIBLIOGRAFI ........................................................................................................... 27
Failure is an option … | 18-05-2011
8 BILAG A ................................................................................................................ 29
9 BILAG B ................................................................................................................ 34
10 BILAG C ................................................................................................................ 35
11 BILAG D................................................................................................................ 39
12 BILAG E ................................................................................................................ 43
1

3. 1 Indledning
Udviklingen af nutidens forståelse af Enterprise Arkitektur som disciplin begyndte tilbage i 1987 med Zachmans
artikel "A framework for information systems architecture" (Zachman J. A., 1987) og har siden resulteret i
talrige EA rammeværker og metoder som FEA, TOGAF, DYA, OIO EA eller EA3 m.fl.
Leder man efter fordelene som en virksomhed kan opnå med en eksplicit Enterprise Arkitektur, ser man typisk
argumenter som
 bedre opfyldelse af strategiske mål
 forbedret forretningsmæssig
performance
 bedre IT understøttelse af
forretningen
 reducerede IT omkostninger m.v.
Men hvordan ser det ud i virkligheden?
IDS Scheer (Software AG) konkluderede
baseret på en undersøgelse fra 2008
(Jonathan Broer, Sven Roeleven, IDS Scheer,
2009), at 66 procent af alle EA programmer
ikke lever op til forventningerne. F IGUR 1-1: G ARTNER H YPE C YCLE FOR EA 2010
I juli 2010 vurderede Gartner den aktuelle modenhed af Enterprise Arkitektur (EA) og EA relaterede emner: EA
og EA værktøjer befinder sig på nuværende tidspunkt i en fase af desillusionering, fordi EA udøvende ikke
fokuserede nok på at integrere EA med forretningen. (Gartner, 2010)
Samtidig viser Gartners undersøgelse at EA rammeværkernes betydning overvurderes betydeligt. Gartner
vurderer derudover at det vil tager mere end 10 år inden EA rammeværker når at blive accepteret som
mainstream.
Allerede i 2005 skriver CIO magasinet om Enterprise Arkitektur: “CIOs go to great lengths to avoid using the
term with their business peers for fear of scaring, alienating or simply boring them to death” (Koch, 2005). Mange
EA specialister har en teknisk baggrund og har svært ved at forklare værdien af EA med ikke teknologiske udtryk
(Gartner, 2009).
Zachman skriver i artiklen ”You can’t cost-justify architecture” (Zachman J. A., You can't "cost-justify" architecture,
2001) at arkitektur er et aktiv, som en virksomhed skal investere i, for at få mulighed for at gøre noget som den
ikke ville kunne uden arkitektur: alignment, integration, change, reduced time-to-market.
Efter forventningerne om de værdier EA kan generere er blevet skuffet, er det ikke blevet lettere at skaffe
opbakning til Enterprise Arkitektur initiativer, hverken hos topledelsen eller potentielle interessenter.
Failure is an option … | 18-05-2011
Forventningen er, at forretningsværdien skal kunne demonstreres og kommunikeres ved at bruge
forretningsledelsens sprog. Gartner forudser at 70 procent af alle succesrige EA initiativer i 2012 vil være ikke-IT
baserede funktioner, som lever op til denne forventning (Gartner, 2009).
I dag er det integrationen mellem EA, BPM og/eller SOA som skal levere nye value propositions.
Værktøjsleverandører og konsulenthuse er allerede kommet på banen. Værktøjer som META, Qualiware eller
ARIS tilbyder EA og BPM funktionalitet, samtidig med at store spillere på markedet, som f.eks. IBM (Jensen,
Cline, & Owen, 2011) og SAP (Eijpe, Laar, Rosenberg, Kuhlmann, & von Rosing, 2011), fokuserer på og
markedsfører synergieffekten som integrationen af EA, BPM og/eller SOA lover at levere.
Hvad er forventningerne til denne integration?
2

4. ”Closer business and IT alignment, a higher ROI and better business results aimed directly at the companies’ bottom line”.
BPM og SOA har siden de dukkede op på business-IT scenen dog kæmpet med lignende problemer som EA: en
stor del af projekterne fejler, det er vanskeligt at dokumentere forretningsværdien og det er derfor svært at få
opbakning fra topledelsen.
1.1 Problemformulering
Som C-level leder er der en stor chance for at man på et tidspunkt skal tager stilling til om et BPM, SOA og/eller
EA program skal iværksættes. Spørgsmålet ”Hvad er egentlig risici med dette initiativ?” skal stilles og risiciene skal
håndteres, dvs. at der skal iværksættes aktiviteter, som reducerer risikoens sandsynlighed eller som afbøder dens
potentielle konsekvenser.
Uden at påvise det matematisk, kan man gå ud fra at risikoen ikke bliver mindre, når initiativet kombinerer flere
komplekse discipliner som EA, SOA og BPM. Dette kræver at man ændrer noget afgørende ved årsagerne til de
problemer, man potentielt kan opleve med de enkelte discipliner.
Når man starter et EA initiativ skal man være klar over at: Failure is an option!
I denne opgave ønsker jeg derfor at undersøge spørgsmålet om
Hvorfor fejler Enterprise Arkitektur (EA) projekter?
Yderlige arbejdsspørgsmål som jeg undervejs ønsker at besvare i denne opgave, er
1. Hvilke årsager nævnes typisk som årsag til at EA initiativer fejler i praksis?
2. Hvilke risici nævnes der i de forskellige EA metoder?
3. Hvordan forslår EA metoderne at disse risici kan håndteres?
4. Matcher EA metodernes risikovurdering de problemer som opleves i praksis?
5. Kan problemer sammenlignes med de problemer som andre IT/forretnings initiativer oplever?
1.2 Metode
For at sikre en fælles forståelse for de anvendte begreber, består opgavens første del af en begrebsafklaring.
Der introduceres først metoder og teorier den foreliggende undersøgelse refererer til. Derefter formuleres et
hovedspørgsmål og en række arbejdsspørgsmål som den foreliggende undersøgelse skal svare på.
Opgaven udgangspunkt i en række af artikler, som forskellige forfattere, analyseinstitutter og konsulenthuse har
offentliggjort, om årsager til problemer og/eller succes i EA initiativer. Der dannes en liste over de typiske
problemer.
For hver af de udvalgte EA metoder undersøges om og hvordan disse tager stilling til risikoen for at et EA initiativ
fejler.
Resultaterne samles i tabelform og sammenholdes derefter med rapporterne fra Gartners (Gartner, 2009) og IDS
Failure is an option … | 18-05-2011
Scheer(Jonathan Broer, Sven Roeleven, IDS Scheer, 2009). På baggrund af disse undersøgelsesresultater, svares
derefter på de undersøgelsens hovedspørgsmål.
1.3 Afgrænsning
Når der i denne opgave tales om risici ved EA initiativer, menes risici, som kan påvirke forløbet af selve EA
initiativet. Der undersøges ikke hvilke nye risici et EA initiativ muligvis introducerer i en virksomhed (f.eks.
sikkerheds sårbarheder, øgede omkostninger for IT-løsninger eller introduktion af nye afhængigheder mellem
forretningsenheder)
Opgaven fokuserer på implementeringsmetode-delen af de forskellige EA varianter, og på hvordan metoden
forholder sig til risiciene ved et EA initiativ.
3

5. Jeg forventer, at læseren har et overordnet kendskab til EA. EA rammeværkerne og metoder beskriver jeg kun
kort. Rendyrkede EA rammeværker uden metodedel, som f.eks. Zachman, falder udenfor rammen af denne
undersøgelse.
Der forsøges ikke at vurdere hvilken EA metode der er den bedste. Valget af EA rammeværk og metode skal altid
tilpasses den aktuelle virksomheds situation.
Der undersøges ikke om integrationen af SOA, BPM og EA har synergieffekter. Mulige årsager for manglende
succes i BPM eller SOA programmer er ligeledes udenfor rammen af denne undersøgelse.
Desuden forudsætter jeg, at læseren har grundlæggende kendskab om forandringsledelse.
2 Begrebsafklaring
2.1 Enterprise Arkitektur
Der findes et væld af definitioner på EA. I denne opgave vil jeg begrænse mig på at nævne nogle få af dem.
”… the organizing logic for business processes and infrastructure reflecting the integration and standardization
requirements of the company’s operating model.” (Ross, Weill, & Robertson, 2006)
“… the consistent set of rules and models that guide the design and implementation of processes, organizational
structures, information flows and the technical infrastructure within an organization.” (Wagter, van den Berg,
Luijpers, & van Steenbergen, 2005)
“The analysis and documentation of an enterprise in its current and future states from an integrated strategy,
business and technology perspective.” (Bernard, 2005)
Nøglebegreberne i disse forskellige definitioner kan sammenfattes med Bernards meget prægnante formel:
Company, Organizing logic, Requirements, strategy Processes, business, Technical
organization, organizational operating model infrastructure,
enterprise structures, current technology
and future states perspective
E A = S + B + T
Enterprise Architecture is the idea of integrating strategy, business and technology
2-1 EA = S + B + T (B ERNARD , 2005)
Failure is an option … | 18-05-2011
4

6. 2.2 Elementer af en Enterprise Arkitektur
De enkelte elementer af en EA tilgang forklares efterfølgende kun i det omfang der inden for rammerne af denne
opgaven er behov for.
Definitionen af de elementer en EA består af og som foreliggende undersøgelse benytter sig af, refererer til Scott
A. Bernards bog om Enterprise Arkitektur (Bernard, 2005)
2.2.1 EA tilgang, metode og rammeværk
Bernards definerer en EA tilgang som ”EA approach – a modeling framework and implementation methodology”
(Bernard, 2005), dvs. At en EA tilgang består af 2 dele:
 EA metoden og
 EA rammeværket
EA metode defineres heri med
”HOW the EA will be implemented and how documentation will be developed, archived and used; including the selection of a
framework, modeling tools and on-line repository” (Bernard, 2005) men et
EA rammeværk beskives som
”A structure for organizing information that defines the scope of the architecture (what the EA program will document) and how
the areas of the architecture relate to each other.” (Bernard, 2005)
2.2.2 EA artefakter, repository og governance
EA artefakter er alle de dokumenter som
”En EA artifact is a documentation product, such as text document, diagram, spreadsheet, briefing slides, or video clip. EA
artifacts document EA components” (Bernard, 2005)
EA repositoriet er stedet hvor EA artefakter lagres og gøres tilgængelige.
”A single place for the storage and retrieval of EA artifacts, that are created using EA software applications (tools)” (Bernard,
2005).
Bernard understreger vigtigheden af at det er nemt og EA
sikkert at tilgå og benytte lageret. Metode
Governance
I sin definition af EA fastslår Bernard, at EA både er en
dokumentations metode og et management program. For EA EA EA
Best Practices rammeværk Artefakter
at leve op til denne definition skal EA være del af en
overordnet governance struktur.
EA værktøjer &
Governance definerer Bernard som
Failure is an option … | 18-05-2011
repository
”A group of policies, decision making procedures, and
management processes that work together to enabler the effective planning and oversight over activities and resources” (Bernard,
2005)
2.2.3 EA best practices
Ikke alle EA tilgange, nævner eksplicit at EA best practices skal være på plads. Men der kan siges at det er best
practice, at EA best practices skal være med i hver EA tilgang.
5

7. 3 Teori
Der er udvalgt tre forskellige EA tilgange: Bernards EA3, OIO EA og TOGAF
Der er udvalgt EA tilgange skal undersøges med hensyn til de formulerede spørgsmål. Metoderne blev udvalgt
fordi de:
 beskriver en fuldstændig EA tilgang, dvs. at der bl.a. eksisterer en EA metode
 har forskellig oprindelse og udbredelse
o akademisk (EA3)
o offentlig sektor (OIO)
o privat sektor (TOGAF)
3.1 Bernard EA3
Bernards EA3 metode består af i fire faser delt op i 20 trin:
 Etablering af programmet
 Valg af EA rammeværk og værktøj
 Dokumentation af Enterprise Arkitekturen 3-1B ERNARDS EA3 CUBE
 Brug og vedligeholdelse af Enterprise Arkitekturen
3.2 TOGAF 9
TOGAF eller TOGAF dokumentationen er delt op i syv områder:
 Introduktion
 Architecture Development Method (ADM)
 ADM Guidelines and Techniques
 Architecture Content Framework
 Enterprise Continuum & Tools
 TOGAF Reference Models
 Architecture Capability Framework
ADM er en metode til at udvikle en EA. ADM er delt op i en separat
start-up fase (preliminary) og ni efterfølgende faser (se billedet 3-2
TOGAF 9 ADM) som gennemgås cyklisk og iterativ.
En beskrivelse af disse faser er vedlagt Bilag A
Derudover hjælper ADM Guidlines and Techniques yderlige med
forklaringer på hvordan ADM kan tilpasses og anvendes. 3-2 TOGAF 9 ADM
3.3 OIO EA
Failure is an option … | 18-05-2011
OIO- Offentlig Information Online- EA er en Enterprise Arkitektur
Guide udarbejdet af IT og Telestyrelsen som led i et forløb, der skal
koordinere det tværoffentlige digitale samarbejde.
OIO EA består af en metoderamme og en dokumentationsramme.
3.3.1 OIO EA metode
Metoden er en procesorienteret metoderamme, som består af fem
aktiviteter, A-E, delt op i 22 trin. OIO understreger, at selv om
3-3 OIO EA METODEN
6

8. processen er iterativ er trinenes rækkefølge ikke lagt fast (se 0 ). Trinene kan også udføres parallelt.
Ud over disse fem aktiviteter relaterer OIO også til to yderlige aktivitetsområder: Principper og Styring, og
Tekniske og forretningsmæssige trends. I OIOs verden er det dog kun EA governance, som EA arkitekten har
ansvaret for.
3.4 Forandringsledels e
Hvad går forandringsprojekter i
Hvad skal forandres? virksomheder typisk ud på?
mission vision mål strategi
For at komme fra nutidens situation, tit
opgaver medarbejder organisation
teknologi processer en situation som ikke længere er
holdbar, en ”brændende platform”, skal
virksomheden flyttes hen til en ønsket
tilstand i fremtiden. For at nå til den
Den brændende platform Fremtid - Vision fremtidige situation, skal noget ændres
på et eller flere områder i en virksomhed, typiske emner er mission, vision, strategi, opgaver, organisation,
processer, teknologi og medarbejdere.
Hver forandring vil typisk møde modstand, enten materiel eller
Forøg presset og følelsen af
psykologisk. Når utilfredsheden med den nuværende situation, ønsket om nødvendighed
at opnår en anden situation i fremtiden og viden om, hvordan man skal nå
derhen er større en modstanden, kan forandringen lykkes 1.
Etabler den ledende koalition. Er
Én metode at håndtere store forandringsprojekter på er blevet grundlagt af nøgleinteressenterne enige?
John Kotter. Kotter konstaterer at 70 procent af alle forandrings initiativer
fejler. For at tackle problemerne, forslår Kotter en 8-trinsproces (Kotter,
Får vision og strategi gjort klar.
1996) HVORFOR skal vi?
Lighederne mellem en forandringsproces og et EA initiativ er meget
tydelige: KOMMUNIKER visionen – fortæl
historien
 EA AS-IS situation  Den brændende platform
 EA TO-BE situation  Fremtidens vision
 EA Management Plan  Vejen frem GØR DET – og styrk
medarbejdernes kompetence
Bernards EA3 cube og dens EA TO-BE
status, gør det meget anskueligt, hvilke
Skab synlige resultater også på
emner EA fokuserer på og hvilke områder kort sigt
der derfor skal regnes med forandringer af:
strategier, processer, teknologier, mål m.v.
Konsolider forbedringer og
Et skoleeksempel på forandring.
Failure is an option … | 18-05-2011
fasthold forandringsforløbet
3-5 B ERNARDS EA3 C UBE Implementer ny procedurer i
organisationens kultur
3-4 K OTTERS O TTE T RIN
1
Change Equation (Gleicher, Beckhard, Harris): D * V * F > R: Dissatisfaction * Vision * First, concrete steps > Resistance
7

9. 4 Analyse
4.1 EA problemer I praksis
4.1.1 Gartner
Den store amerikanske forsknings og rådgivningsvirksomhed, offentliggjorte i 2009 en liste over de 10 største
faldgruber ved et EA initiativ (Gartner, 2009)
Problem Løsning
G1 EA Chefarkitekten kender til EA, men er ikke Skal erstattes med nogen, som har bløde kompetencer
en effektiv leder som entusiasme, lidenskab og kan kommunikere.
G2 Utilstrækkelig forståelse og understøttelse EA skal sælges til topledelsen først. Fokus på uddannelse
hos nøgleinteressenter uden for EA teamet. og kommunikation.
G3 Forretningen er ikke involveret. IT og Enterprise arkitekter skal involvere sig i forretningen og,
forretningsmål er ikke tilpasset hinanden sammen med andre kolleger, i forretningsarkitekturen
G4 Domain Level arkitektur Holistisk EA best practice, som inkluderer forretnings-,
informations- og løsningsarkitektur
G5 AS-IS status dokumenteres først. Værdien af Skab sammenhæng med forretningen og udvikle TO-BE
EA realiseres for sent. status først
G6 EA gruppen gør det meste af arbejdet alene EA processen skal ledes og ikke påtvinges. Virtuelle teams
(uden input fra forretningen) => resulterer i
manglende buy-in hos forretningen
G7 Værdien af EA måles og kommunikeres ikke, Vis og kommuniker alle succeshistorier inklusive
fordi den kun er synlig indirekte. værdimålinger
G8 Kassetænkning … arkitektur for proces, Fokus på sammenhæng mellem forretningsenheder
information, teknik og løsning for
forretningsenheder modelleres uafhængigt og
uden hensyn til integration og
interoperabilitet.
G9 EA governance introduceres for sent i Skal udvikles samtidig med indholdet
forløbet
G10 Der bruges ikke tid nok på kommunikation Udvikling og iværksættelse af en kommunikations plan
som er tilpasset til modtagerne Failure is an option … | 18-05-2011
8

10. 4.1.2 IDS Scheer
IDS Scheer (Software AG) konkluderede baserende på en undersøgelse fra 2008 (Jonathan Broer, Sven Roeleven,
IDS Scheer, 2009), at 66 % af alle EA programmer ikke lever op til forventningerne.
Problem Løsning
S1 Kun i 40 % af alle virksomheder er ”objectives Klare mål fra begyndelsen, forventningsafstemning, få EA
and policy” del af EA programmet governance på plads, have en standard projekt metode,
S2 Svært at skabe forbindelsen mellem EA og
forretningsstrategi (EA + BPM)
S3 Manglende bevidsthed om EA som
forretningsaktivitet (asset)
S4 Iværksættelsen af EA tager mere tid end
forventet, resultater realiseres senere
S5 Manglende C-level understøttelse Udnævn en Chef Enterprise Arkitekt som kommunikerer
med C-level ledelsen
S6 Manglende engagement hos nøgleinteressenter Sørg for at forretningssiden er involveret
S7 Finansielle og politiske spørgsmål forpurrer EA
projektet
S8 CIO eller IT manager har ansvaret for udvalg Sørg for at forretningssiden er involveret i udvalget af
af EA værktøjet værktøjet.
Failure is an option … | 18-05-2011
9

11. 4.1.3 Analyse af EA problemer i praksis
Det er meget tydeligt, at der kun nævnes få EA faglige problemer, som f.eks. EA projekter som kun fokuserer på
domain arkitektur eller siloarkitektur.
Valg af det forkerte EA rammeværk, EA metode eller EA værktøj nævnes ikke som problem.
En komprimeret liste af problemer ved EA initiativer kunne således være:
 Den udnævnte chefarkitekten er ikke en effektiv leder
 Manglende support fra nøgleinteresser og C-level, forretningen er ikke involveret
 For lidt kommunikation, især om de værdier EA skaber
 IT og forretningens mål i EA projektet er ikke tilpasset (”aligned”)
 Manglende EA Governance
 Manglende viden om EA
Betragter man et EA program med forandringsledelsens briller, så viser der sig iøjnefaldende overensstemmelser
mellem problemer med EA programmer i praksis og den måde hvordan store forandringsprocesser ifølge Kotters
8-trins-model skal gennemføres.
Dette gælder især for Gartners liste.
Forøg presset og følelsen af
EA Chefarkitekten kender til EA, men er ikke nødvendighed
en effektiv leder
Utilstrækkelig forståelse og understøttelse hos
Etabler den ledende koalition. Er
nøgleinteressenter uden for EA teamet. nøgleinteressenterne enige?
Forretningen er ikke involveret. IT og
forretningsmål er ikke tilpasset hinanden
Får vision og strategi gjort klar.
Domain Level arkitektur HVORFOR skal vi?
AS-IS status dokumenteres først. Værdien af
EA realiseres for sent. KOMMUNIKER visionen – fortæl
historien
EA gruppen gør det meste af arbejdet alene
(uden input fra forretningen) => resulterer i
manglende buy-in hos forretningen GØR DET – og styrk
medarbejdernes kompetence
Værdien af EA måles og kommunikeres ikke,
fordi den kun er synlig indirekte.
Kassetænkning … arkitektur for proces, Skab synlige resultater også på
kort sigt
information, teknik og løsning for
forretningsenheder modelleres uafhængigt og
uden hensyn til integration og
Failure is an option … | 18-05-2011
Konsolider forbedringer og
interoperabilitet. fasthold forandringsforløbet
EA governance introduceres for sent i forløbet
Der bruges ikke tid nok på kommunikation Implementer ny procedurer i
organisationens kultur
Meget tyder på at allerede i startfasen af EA projekter kunne findes roden for de problemer som gør at EA
projekter fejler. Hvis ikke i opstartsfasen bliver tydeligt forklaret, hvor EA er et vigtigt initiativ, og
nøgleinteressenterne ikke samles, mangler de bærende fundamentet til det videre EA forløb.
10

12. 4.2 EA metodernes håndtering af risici i EA initiativer
4.2.1 Bernard EA3
Bernard dedikerer et helt kapitel af sin bog til spørgsmålet om værdien og risici ved at skabe en Enterprise
Arkitektur 2. Han nævner fem forskellige typer af risici som potentielt kunne påvirke et EA program:
 Finansielle risici: Stort initial budget; senere besparelser på EA budgettet kan gøre EA
informationerne værdiløse, hvis de ikke kan vedligeholdes.
 Mangel på accept: store forandringer i strategi, forretning og teknologi, kan resultere i spændinger
mellem forskellige nøgleinteressenter
 Tab af nøglemedarbejdere: tab af uddannet EA personale fører til forsinkelser og øgede
omkostninger
 Forsinkelser: EA programmets tidsplan kan påvirkes fra forskellige sider, som kan resultere i at
programmet afbrydes
 Dokumentationsværktøjer: Det udvalgte værktøjet bestemmer hvor intuitive og informative EA
programmets dokumenter er.
Bernard beskriver derudover også nogle generelle foranstaltninger der kan reducere sandsynligheden for de
nævne risici og for at reducere deres negative indvirkning:
 Styrke ledelsesopbakning til EA programmet
 Sørge for finansiel stabilitet
 Lade være med at være den første som benytter et nyt værktøj
 Sørge for at have uddannet backup personale til EA teamet
 Benytte en detaljeret EA metode
 Sørge for at program manager har grundlæggende kompetence vedrørende personaleledelse, budget,
performance og håndtering af nøgleinteressenter
Bernards EA3 metode består af i fire faser som er delt op i 20 trin. Disse trin analyseres og vurderes herefter med
hensyn til de problemer i EA programmer som den foreliggende undersøgelse har fundet frem til i kapitel 04.1.
Failure is an option … | 18-05-2011
2
(Bernard, 2005), Chapter3: The value and risk of creating an Enterprise Architecture
11

13. Problem Håndteres af Aktivitet Vurdering
EA3 trin 1 Trinet tager hensyn til finansielle
G1 risici (sørge for finansiel stabilitet) og
Etablering af EA programmet og udnævnelse af sørger for ledelsesopbakning fra
EA Chefarkitekten Chef Arkitekten tilstrækkelige resurser begyndelsen
kender til EA men er (budget, personale m.v.) og myndighed.
ikke en effektiv leder Dannelse af EA team som består af EA
arkitekter og forskellige nøgleinteressenter
G2 EA3 trin 4 Trinet fokuserer på risikoen vedr.
manglende acceptanse.
Utilstrækkelig Udvikling af EA kommunikationsplan og sørge
forståelse og for buy- in, fokus på ikke-tekniske Fokus på kommunikation af værdien
understøttelse hos nøglepersoner og EA slutbruger. Inkluder som EA skaber
nøgleinteressenter eksempler på hvordan EA skaber værdi, sørg
udenfor EA teamet. for at dokumentationen er tilgængelig for alle Bernards metode tager således hensyn
til de nogle af de problemer som
EA3 trin20 Gartner (Gartner, 2009) nævner
Frigiv regelmæssige opdateringer af EA
management planen, Kommuniker hvordan
EA har reduceret omkostninger, forbedret
alignment etc.
G3 EA3 trin 1 EA teamet består af arkitekter og
andre nøgleinteressenter
Forretningen er ikke Etablering af EA programmet og udnævnelse af
involveret. IT og Chef Arkitekten tilstrækkelige resurser
forretningsmål er ikke (budget, personale m.v.) og myndighed.
tilpasset Dannelse af EA team som består af EA
arkitekter og forskellige nøgleinteressenter
G4 EA3 trin 7
Domain Level Identifikation af EA komponenter som skal
arkitektur dokumenteres
G5 EA3 trin 11 Bernards metode begynder med
dokumentationen af AS-IS
AS-IS status Evaluering om eksisterende dokumentation situationen.
dokumenteres først. kan bruges i EA programmet => AS-IS
Værdien af EA
realiseres for sent. EA3 trin 11
Skab dokumentation af EA komponenter som
mangler => AS-IS
G6 EA3 trin 5
Failure is an option … | 18-05-2011
EA gruppen gør det Valg af EA dokumentations rammeværk med
meste af arbejdet alene input fra EA team og nøgleinteressenter.
(uden input fra
forretningen) =>
resulterer i manglende
buy-in hos forretningen
12

14. G7 EA3 trin 4 Trinet fokuserer på risikoen vedr.
manglende accept.
Værdien af EA måles Udvikling af EA kommunikationsplan og sørge
og kommunikeres ikke, for buy-in, fokus på ikke-tekniske Bernards metode tager således hensyn
fordi den kun er synlig nøglepersoner og EA slutbruger. Inkludere til de nogle af de problemer, som
indirekte. eksempler på hvordan EA skaber værdi, sørge Gartner (Gartner, 2009) nævner
for at dokumentationen er tilgængelig for alle
G8 EA3 trin 6 Crosscuttings sørger for forbindelsen
mellem forskellige enheder af en
Kassetænkning … Identifikation af brancher/segmenter (“Lines of organisation
arkitektur for proces, business”) og delte aktiviteter (“crosscuttings”)
information, teknik og
løsning for
forretningsenheder
modelleres uafhængigt
og uden hensyn til
integration og
interoperabilitet.
G9 EA3 trin 3
EA governance Etablering af EA governance som også opretter
introduceres for sent i en forbindelse med forretningens andre
forløbet managementprocesser (strategi planlægning,
projekt management, sikkerhed,
personaleplanlægning)
G10 EA3 trin 4 Trinet fokuserer på risikoen vedr.
manglende acceptanse.
Der bruges ikke tid Udvikling af EA kommunikationsplan og sørge
nok på kommunikation for buy- in, fokus på ikke-tekniske Bernards metode tager således hensyn
nøglepersoner og EA slutbruger. Inkludere til de nogle af de problemer som
eksempler på hvordan EA skaber værdi, sørge Gartner (Gartner, 2009) nævner
for at dokumentationen er tilgængelig for alle
EA3 trin20
Frigive regelmæssige opdateringer af EA
management planen. Kommunikere hvordan
EA har reduceret omkostninger, forbedret
alignment etc.
S1 EA3 trin 3
Kun i 40 % af alle Etablering af EA governance som også opretter
virksomheder er en forbindelse med forretningens andre
”objectives and policy” managementprocesser (strategi planlægning,
Failure is an option … | 18-05-2011
del af EA programmet projekt management, sikkerhed,
personaleplanlægning)
S2
Svært at skabe
forbindelsen mellem
EA og
forretningsstrategi (EA
+ BPM)
13

15. S3
Manglende bevidsthed
om EA som
forretningsaktivitet
(asset)
S4
Iværksættelsen af EA
tager mere tid end
forventet, resultater
realiseres senere
S5 EA3 trin 1 Trinet tager hensyn til finansielle
risici (sørge for finansiel stabilitet) og
Manglende C-level Etablering af EA programmet og udnævnelse af sørger for ledelsesopbakning fra
understøttelse Chef Arkitekten tilstrækkelige resurser begyndelsen
(budget, personale m.v.) og myndighed.
Dannelse af EA team som består af EA
arkitekter og forskellige nøgleinteressenter
S6 EA3 trin 4 Trinet fokuserer på risikoen vedr.
manglende accept.
Manglende Udvikling af EA kommunikationsplan og sørge
engagement hos for buy-in, fokus på ikke-tekniske Bernards metode tager således hensyn
nøgleinteressenter nøglepersoner og EA slutbruger. Inkludere til de nogle af de problemer som IDS
eksempler på hvordan EA skaber værdi, sørge Scheer (Jonathan Broer, Sven
for at dokumentationen er tilgængelig for alle Roeleven, IDS Scheer, 2009) nævner
S7 EA3 trin 1 Trinet tager hensyn til finansielle
risici (sørge for finansiel stabilitet) og
Finansielle og politiske Etablering af EA programmet og udnævnelse af søger for ledelsesopbakning fra
spørgsmål forpurrer Chef Arkitekten tilstrækkelige resurser begyndelsen
EA projektet (budget, personale m.v.) og myndighed.
Dannelse af EA team som består af EA
arkitekter og forskellige nøgleinteressenter
S8 EA3 trin 5
CIO eller IT manager Valg af EA dokumentations rammeværk med
har ansvaret for udvalg input fra EA team og nøgleinteressenter.
af EA værktøjet
EA3 trin 8
Valg af dokumentationsmetoden (Chef
Failure is an option … | 18-05-2011
Arkitekt, EA team og flere nøgleinteressenter)
EA3 trin 9
Valg af værktøj til EA dokumentation (Chef
Arkitekt og EA team)
EA3 trin 10
Valg og etablering af EA repository til
dokumentation (Chef Arkitekt og EA team)
14

16. 4.2.2 TOGAF ADM
TOGAF 9 indeholder i modsætning til EA3 ikke et eksplicit kapitel som henviser til risici ved gennemførslen af et
EA program. Til gengæld tager TOGAF 9 speciel hensyn til emnerne håndtering af nøgleinteressenter og EA
kompetencer.
Stakeholder management: “Stakeholder Management is an important discipline that successful architecture practitioners
can use to win support from others. It helps them ensure that their projects succeed where others fail.” (The Open Group,
2009)
EA skills framework: “Skills frameworks provide a view of the competency levels required for specific roles. They define:
the roles within a work area, the skills required by each role, the depth of knowledge required to fulfill the role successfully “
(The Open Group, 2009)
Ud over trinene i ADM metoden, analyseres herefter også de 2 ovenstående emner med hensyn til de problemer i
EA programmer som den foreliggende undersøgelse har fundet frem til i kapitel 0
Problem Aktivitet Vurdering
G1 I ”skills framework” (The Open Group, TOGAFs beskriver omfattende,
2009, s. kapitel 52) beskrives EA manageren hvilke kompetencer der forventes
EA Chefarkitekten som ekspert på områder som leadership, fra de forskellige roller I et EA
kender til EA men er teamwork, interpersonal, communication, program, bl.a. EA manageren
ikke en effektiv leder analyse, stakeholder management og risk
management.
En ekspert beskrives om person der har
”omfattende og væsentlig praktisk erfaring og
anvendt viden om emnet”
”Communication and team building are key to the
successful role of the enterprise architect. The mix of
good technical skill and the ability to lead are
crucial to the job. The enterprise architect should be
viewed as a leader in the enterprise by the IT
organization, the clients they serve, and
management.”
G2 Et af målene i TOGAF ADM Phase A er:
Utilstrækkelig ”define the relevant stakeholders, and their concerns
forståelse og and objectives” (The Open Group, 2009, s.
understøttelse hos TOGAF Step 7.4.2). Processen beskrives
nøgleinteressenter yderlige i ”Steps in the stakeholder management
udenfor EA teamet. process” (The Open Group, 2009, s. TOGAF
Failure is an option … | 18-05-2011
step 24.3). Nøgleudsagn er:
“The most powerful stakeholders can be identified
early […] this ensures their support and improves
the quality of the models produced.”
“… communicating […] early and frequently, […]
they fully understand the architecture process, and
the benefits of enterprise architecture; […]”
“The […] team can more effectively anticipate likely
reactions […], and […] plan the actions […]
avoiding or addressing any negative reactions”
15

17. Problem Aktivitet Vurdering
G3 ADM Phase B: Business Architecture Det er her en forbindelse mellem
TOGAF EA og et BPM program
Forretningen er ikke “the development of a Business Architecture to kunne skabes. Forbindelsen som
involveret. IT og support an agreed Architecture Vision” TOGAF skaber i dette trin er dog
forretningsmål er ikke meget teknisk fokuseret.
tilpasset hinanden
G4 ADM Phase C: Information Systems
Architectures og Phase D: Technology
Domain Level Architecture
arkitektur
G5 ADM Phase B: Business Architecture, Faserne B, C og D går ud fra at der
Phase C: Information Systems først skabes ”Baseline Descriptions”
AS-IS status Architectures, Phase D: Technology (=> AS-IS) af de forskellige
dokumenteres først. Architecture arkitekturer
Værdien af EA
realiseres for sent. Nøgleudsagner : “knowledge of the Business
Architecture is a prerequisite for architecture work in
any other domain”
G6
EA gruppen gør det
meste af arbejdet alene
(uden input fra
forretningen) =>
resulterer i manglende
buy-in hos forretningen
G7 ADM Phase A : 7.4.9 Define the Target TOGAF tager højde for AT det skal
Architecture Value Propositions and KPIs gøres, men er ikke meget detaljeret
Værdien af EA måles vedr. HVORDAN dette kunne
og kommunikeres ikke, gøres.
“Review and agree the value propositions with the
fordi den kun er synlig
sponsors and stakeholders concerned “
indirekte.
“Define the performance metrics and measures to be
built into the enterprise architecture to meet the
business needs”
Failure is an option … | 18-05-2011
16

18. Problem Aktivitet Vurdering
G8 TOGAF afsnit: 29. Interoperability Interoperabilitet er en integreret del
Requirements af alle faser I TOGAF ADM
Kassetænkning …
arkitektur for proces,
In the Architecture Vision (Phase A), the nature and
information, teknik og
security considerations of the information and service
løsning for
exchanges are first revealed within the business
forretningsenheder
scenarios.
modelleres uafhængigt
og uden hensyn til
integration og In the Business Architecture (Phase B), the
interoperabilitet. information and service exchanges are further defined
in business terms.
In the Data Architecture (Phase C), the content of
the information exchanges are detailed using the
corporate data and/or information exchange model.
In the Application Architecture (Phase C), the way
that the various applications are to share the
information and services is specified.
In the Technology Architecture (Phase D), the
appropriate technical mechanisms to permit the
information and service exchanges are specified.
In Opportunities & Solutions (Phase E), the actual
solutions (e.g., Commercial Off-The-Shelf (COTS)
packages) are selected.
In Migration Planning (Phase F), the
interoperability is logically implemented.
G9 ADM Preliminary Phase TOGAF 9 kræver at governance
kommer på plads allerede i
EA governance […] major output of this phase is a framework for opstartsfasen
introduceres for sent i architecture governance. [..] i.e., what type of
forløbet governance repository characteristics are going to be
required, what relationships and status recording are
necessary to ascertain which governance process
(dispensation, compliance, take-on, retirement, etc.)
has ownership of an architectural artifact.”
 Confirm Governance and Support
Frameworks
Failure is an option … | 18-05-2011
Phase G: Implementation Governance
“[…] the time at which they are formally started
and completed should be adapted to the situation at
hand in accordance with the established architecture
governance”
I afsnit 50. Architecture Governance (The
Open Group, 2009) leverer TOGAF
uddybende forklaringer. Architecture
Governance overvågnes og styres af et
Architecture Board,
17

19. Problem Aktivitet Vurdering
G10 ADM Stakeholder Management og TOGAF gør vigtigheden af
TOGAF 36.2.12 Communications Plan kommunikationen tydeligt.
Der bruges ikke tid
nok på kommunikation
“Identification of a communications timetable,
showing which communications will occur with
which stakeholder groups at what time and in what
location”
S1
Kun i 40 % af alle
virksomheder er
”objectives and policy”
del af EA programmet
S2 Iværksættelsen af EA tager mere tid end
forventet, resultater realiseres senere
Svært at skabe
forbindelsen mellem
EA og
forretningsstrategi (EA
+ BPM)
S3 ADM Stakeholder Management
Manglende bevidsthed CxO level
om EA som
forretningsaktivitet “This stakeholder group is interested in the high-
(asset) level drivers, goals, and objectives of the
organization, and how these are translated into an
effective process and IT architecture to advance the
business”
KEEP SATISFIED
S4 TOGAF ADM afsnit 24. Stakeholder
Management
Iværksættelsen af EA
tager mere tid end
forventet, resultater
realiseres senere
S5 ADM Preliminary Phase sørger for At politiske eller finansielle
“sponsor’s sign-off to proceed” spørgsmål forpurrer projektet kan
Manglende C-level aldrig udelukkes. ”Salgsfasen” er
understøttelse ADM Phase E: Opportunities & afgørende. TOGAFs tiltag på dette
Solutions område er dog ret begrænset
Failure is an option … | 18-05-2011
TOGAF afsnit 32. Capability-Based
Planning
S6 ADM Preliminary Phase og TOGAF Det er evalueringen som beskrives,
afsnit 42. Tools for Architecture men IKKE hvem der skal være med
Manglende Development beskriver valget af EA til valget
engagement hos værktøjer
nøgleinteressenter
18

20. 4.2.3 OIO
Nævner OIO risici som EA3 eller TOGAF?
I modsætning til Bernards EA3 metode, indeholder OIA EA ikke noget særlig kapitel vedrørende de risici som
kunne true et EA initiativ. Der er heller ikke skrevet særlig meget om håndtering af nøgleinteressenter.
OIO leverer dog en definition af forskellige arkitektroller og kompetenceprofiler (se 0)
Problem Aktivitet Vurdering
G1 OIO definerer en række arkitektroller bl.a. Ledelses og
Enterprise Arkitekten. Personen skal have Kommunikationskompetencer er
EA Chefarkitekten indflydelse på virksomhedens beslutninger og ikke vurderet som at være særlig
kender til EA men er taler både forretningssprog og teknikersprog. vigtige … teknologi, analyse og
ikke en effektiv leder strategi kompetence vurderes at
De forventede kompetencer vises i et profil være vigtigere
G2 OIO EA trin A3.5: Vision, mål, strategier
Utilstrækkelig ”vigtigt at indse, at man næppe skal forvente total
forståelse og enighed imellem forretningens beslutningstagere
understøttelse hos […] man laver en interessentanalyse”
nøgleinteressenter
udenfor EA teamet. EA kommunikationsprocesser
”Barrieren […] er oftest at den ikke er kendt eller
forstået.. Kommunikation kan indeholde:
o EA forklaring: rollespecifikke og praktiske
vejledninger (f.eks. hvad betyder arkitekturen for
udvikleren
o EA publikation: opdateret og lettilgængelig
dokumentation (intranet, værktøjsintegration). En
tilgængelig EA gør det lettere for andre at genbruge
og forbedre den.
o EA evangelisering; høj synlighed i organisationen.
Omfatter præsentationer, kommunikation
af succeshistorier, mv.
Failure is an option … | 18-05-2011
19

21. Problem Aktivitet Vurdering
G3 OIO EA trin A5. Vision, mål og OIO tager højde for at konsolidere
strategier IT og forretning
Forretningen er ikke
involveret. IT og ”Trinet konsoliderer organisationens Forretningssiden inkluderes
forretningsmål er ikke forretningsmæssige side vision, mål, strategier, og
tilpasset hinanden analyserer hvilke kritiske succesfaktorer, der har
afgørende betydning for at målene og strategierne
realiseres. Der udvikles ingen nye mål og strategi i
dette trin. Formålet er at sikre at efterfølgende EA
aktiviteter er forankrede hos, og i overensstemmelse
med forretningens behov.”
OIO EA aktivitet B: Forretning
”Den fremtidige forretning beskrevet i mere
operationelle termer”
G4
Domain Level
arkitektur
G5 OIO EA Trin C1. Informationsarkitektur OIO EA forudsætter an man
udarbejder det nuværende stadie
AS-IS status OIO EA Trin C2. Applikationsarkitektur først … men fordi dette kan tager
dokumenteres først. lang til anbefaler OIO at arbejdet
Værdien af EA OIO EA Trin C3. Servicearkitektur
kan foregå parallelt og at områder
realiseres for sent. OIO EA Trin C1. Teknologiarkitektur skal fravælges hvor muligt.
”Trinet beskriver den nuværende og den fremtidige
informationsarkitektur… ”
”Hvis man designer den fremtidige arkitektur
indenfor et af de fire område, skal man dokumentere
den nuværende indenfor dette område.”
G6 OIO EA trin D2. Muligheder
EA gruppen gør det ” Det er vigtigt at spørge eksplicit ind til
meste af arbejdet alene forbedringsmuligheder, bredt i organisationen. Når
(uden input fra man udvikler en enterprise arkitektur, kommer man
forretningen) => typisk meget rundt i organisationen, og i kontakt
resulterer i manglende med mange med gode ideer,der bare aldrig er nået
buy-in hos forretningen frem til it-afdelingen.”
X1. Forretningsmæssige trends
Failure is an option … | 18-05-2011
”Ved interviews med forretningssiden bør der tages
referat, og disse referater bør godkendes af de
interviewede”
EA Review Board (EARB)
”mødes ca. 8-12 gange årligt og træffer
beslutninger vedr.arkitekturen, […] Medlemmerne
bør rekrutteres fra forretning og teknik, og er
personer med pondus i deres egen organisation, og et
bredt udsyn.”
20

22. Problem Aktivitet Vurdering
G7 OIO EA trin A5.1 Vision, mål, strategier
samt kritiske succesfaktorer (KSF).
Værdien af EA måles
og kommunikeres ikke,
OIO EA trin A5.2 Metrikker (målepunkter)
fordi den kun er synlig
på de ovenstående – fx KPIs (key
indirekte.
performance indicators).
G8
Kassetænkning …
arkitektur for proces,
information, teknik og
løsning for
forretningsenheder
modelleres uafhængigt
og uden hensyn til
integration og
interoperabilitet.
G9 OIO EA trin A2 EA governance strategi Governance introduceres tideligt i
forløbet
EA governance - økonomiske, organisatoriske og andre
introduceres for sent i rammer
forløbet - Identifikation af nøgle-aktører og
beslutningstagere
Dermed bliver disse involveret allerede fra
start.
Evt. interessentanalyse. overblik over alle
interessenter i EA , deres respektive
interesser, og planlægger involvering i EA
forløbet.
G10 OIO EA trin Y3
Der bruges ikke tid EA Governance,
nok på kommunikation kommunikationsprocesser
”Barrieren […] er oftest at den ikke
er kendt eller forstået.. Kommunikation kan
indeholde:
o EA forklaring: rollespecifikke og praktiske
vejledninger (f.eks. hvad betyder arkitekturen for
udvikleren
o EA publikation: opdateret og lettilgængelig
dokumentation (intranet, værktøjsintegration). En
tilgængelig EA gør det lettere for andre at genbruge
Failure is an option … | 18-05-2011
og forbedre den.
o EA evangelisering; høj synlighed i organisationen.
Omfatter præsentationer, kommunikation af
succeshistorier, mv.
S1
Kun i 40 % af alle ”Verifikation og justering af denne konsolidering,
virksomheder er typisk gennem en workshop. Topledelsen bør være
”objectives and policy” repræsenteret her, således at den konsensus der opnås
del af EA programmet afspejler et balanceret syn på forretningen, og
dermed forankrer EA indsatsen
21

23. Problem Aktivitet Vurdering
S2 OIO EA trin A5. Vision, mål og OIO tager højde for at konsolidere
strategier IT og forretning
Svært at skabe
forbindelsen mellem ”Trinet konsoliderer organisationens Forretningssiden inkluderes !
EA og forretningsmæssige side vision, mål, strategier, og
forretningsstrategi (EA analyserer hvilke kritiske succesfaktorer, der har
+ BPM) afgørende betydning for at målene og strategierne
realiseres. Der udvikles ingen nye mål og strategi i
dette trin. Formålet er at sikre at efterfølgende EA
aktiviteter er forankrede hos, og i overensstemmelse
med forretningens behov.”
OIO EA trin X1: Forretningsmæssige
trends
”indsamle information bredt, via både eksterne kilder
(såsom rapporter fra analysebureauer) og via interne
(visioner hos ledere). I A5 konsolideres disse og
konkretiseres til forretningsstrategier, så der dannes
et samlet billede af organisationens
forretningsmæssige prioriteter”
OIO EA aktivitet B: Forretning
Den fremtidige forretning beskrevet i mere
operationelle termer
S3
Manglende bevidsthed
om EA som
forretningsaktivitet
(asset)
S4 OIO EA trin D2. Muligheder OIO EA går med dette trin efter
quick wins …
Iværksættelsen af EA ”Trinet identificerer projekter der måske ikke er
tager mere tid end strategiske og en del af entreprise arkitekturen, men
forventet, resultater som er taktiske og på kort tid og uden en stor indsats
realiseres senere kan give en gevinst i form af effektivitet, besparelser
og større kvalitet.”
S5 A2. EA governance strategi
Manglende C-level ”Trinet sigter mod, fra start, at opstille rammer der
understøttelse skal sikre at enterprise arkitekturen kan realiseres, at
nøgle-aktører tages i ed og involveres …”
Failure is an option … | 18-05-2011
22

24. Problem Aktivitet Vurdering
S6 OIO EA trin A2
Manglende EA governance strategi der udføres
engagement hos evt. en interessentanalyse: overblik over
nøgleinteressenter alle interessenter i EA , deres respektive
interesser, og planlægger involvering i EA
forløbet.
OIO EA trin Y3
EA Governance, kommunikationsprocesser
”Barrieren […] er oftest at den ikke
er kendt eller forstået.. Kommunikation kan
indeholde:
o EA forklaring: rollespecifikke og praktiske
vejledninger (f.eks. hvad betyder arkitekturen for
udvikleren
o EA publikation: opdateret og lettilgængelig
dokumentation (intranet, værktøjsintegration). En
tilgængelig EA gør det lettere for andre at genbruge
og forbedre den.
o EA evangelisering; høj synlighed i organisationen.
Omfatter præsentationer, kommunikation af
succeshistorier, mv.
S7
Finansielle og politiske
spørgsmål forpurrer
EA projektet
S8 OIO EA A4. EA projekt charter OIO giver ingen anbefalinger om
hvem der vælger værktøjer eller
CIO eller IT manager hvordan dette skal gøres
har ansvaret for valg af
EA værktøjet
Failure is an option … | 18-05-2011
23

25. 4.3 Resultater
Fejl! Henvisningskilde ikke fundet. 3 viser EA Problem EA3 TOGAF OIO
metodernes evne til at adressere de problemer, som i praksis
ofte fører med sig at EA programmer fejler. ADM EA
G1 + + -
4.3.1 EA3
Bernards EA3 metode har en meget bred dækning af de fleste G2 + + +
problemer som EA oplever i praksis og som Gartner og IDS G3 + - +
Scheer nævner i deres rapporter.
G4 + +
Der skal dog siges, at EA3 metoden, når den gør opmærksom
på, at man som EA ansvarlig skal forholde sig til et problem, G5 - - +/-
ikke giver meget hjælp til, hvordan man skal gøre det. G6 + +
Et eksempel: Bernard skriver i EA3 om, at kommunikation er G7 + +/- +
vigtigt, men når man undersøger man EA rollerne og deres
G8 + +
ansvar, har ingen i teamet særlige kommunikationsopgaver.
G9 + + +
4.3.2 TOGAF ADM
TOGAF håndterer ikke problemer i gennemførelsen af EA G10 + + +
programmer, som Gartner og IDS Scheer nævner i deres S1 + +
rapporter, i samme udstrækning som de to andre metoder.
S2 - +
Forfatteren skal dog medgive at TOGAF metoden, på de
S3 +
områder den adresserer, er meget udspecificeret. Især
vigtigheden af EA chefarkitektens kompetenceprofil og S4 + +
håndtering af nøgleinteressenterne skal her fremhæves.
S5 + - +
4.3.3 OIO EA S6 + - +
OIO EA dækker ligeledes over en stor række af EA
S7 +
virkelighedens problemer. Forfatter ser OIO EA som meget
nemt forståelig metode. OIO EA har ikke fokus nok på S8 + -
chefarkitektens leder kompetence og forandrings aspektet
som der er i EA programmer.
Failure is an option … | 18-05-2011
3
For problemer som der ikke kunne klart svares på om metoderne adresserer dem, er svaret blank (de hvide felter)
24

26. 5 Konklusion
Med denne undersøgelse prøver jeg at svare på, hvorfor mange EA programmer fejler. Undersøgelser (Gartner,
2009) (Jonathan Broer, Sven Roeleven, IDS Scheer, 2009) nævner en række forskellige årsager. Foruden
problemer som manglende kendskab til EA og manglende EA Governance, anføres dårlig ledelse, manglende
kommunikation og manglende IT-business strategi alignment som hovedproblemer. De tre sidstnævnte er typiske
i store forandringsprocesser.
Kun én af de tre undersøgte metoder, EA3, gør direkte opmærksom på, at gennemførelsen af EA programmer
generelt er truet af risici såsom finansielle risici, mangel på accept hos nøgleinteressenter, personaleproblemer og
forsinkelser.
Metoden, EA3, anbefaler samtidig nogle generelle aktiviteter, som skal modvirke disse risici, dog er aktiviteterne
ikke udspecificeret. De andre metoder lægger vægt på håndtering af nøgleinteressenter og EA teamets
kompetencer. Der er dog i det hele taget ikke meget fokus på de risici, som EA programmer er udsat for.
Analysen af de udvalgte EA metoder viser, at alle tre i høj eller meget høj grad adresserer de problemer, som man
oplever i EA programmernes virkelighed. Gartners undersøgelse positionerer det problem, at der bliver udnævnt
EA chefarkitekter, som er dårlige ledere, som absolut hovedårsag til problemer i EA initiativer. Alle tre metoder
tager stilling til EA chefarkitektens kompetencer. Kun TOGAF pointerer meget klart chefarkitektens betydning.
EA3 behandler emnet overfladisk, mens OIO EA klart underprioriterer emnet.
Hvorfor fejler EA projekter? De undersøgte metoder dækker i meget stort omfang de problemer, som analyserne
finder frem til. Forandringsledelsens vinkel på EA projekter tager metoderne dog kun i meget begrænset omfang
hensyn til.
Denne undersøgelse konkluderer derfor, at en stor del af problemerne i EA projekter ikke skyldes EA metoderne,
men manglende fokus på forandringsledelse i EA programmer.
6 Perspektivering og Metodekritik
Et af arbejdsspørgsmålene har været om problemerne i forløbet af EA programmer kan sammenlignes med and
IT-forretningsinitiativer. I Bilag E findes nogle eksempler på statistiker, som undersøger hvor tit IT projekter
fejler. På grund af tidsmangel har jeg ikke undersøgt fænomenet nærmere men kort sagt kommer de anførte
undersøgelser til det resultat at 40-70 procent af alle IT projekter fejler
Begrænsede tidsresurser har begrænset omfanget af min undersøgelse, om de enkelte Enterprise Arkitektur
metoder har et svar på problemerne i EA i praksis. Det begrænsede kendskab til de udvalgte metoder kan betyde,
at enkelte positive eller negative vurderinger er blevet truffet på et for spinkelt grundlag. Især TOGAF er et
meget omfattende værk, og det ville kræve meget mere tid at analysere denne metode fyldestgørende.
Fordi metodernes oprindelse er forskellige, kan der sættes spørgsmålstegn ved, om det overhoved er rimeligt at
sammenligne dem. Især OIO EA er jo en metode, som særlig tilpasset EA projekter i danske myndigheder.
Failure is an option … | 18-05-2011
Vurderingen om en EA metode håndterer et bestemt problem eller ej er foregået uden klart definerede kriterier.
Bare det faktum, at der findes informationer i den vurderede EA metode, som omhandler det pågældende
problem, resulterede i, at metoden blev vurderet positiv.
Selv om to metoder begge blev vurderet positiv, kan der være store forskel på metoderne. Man kunne overveje at
vægte metodernes dækning af de undersøgte problemer, f.eks. metoden dækker ikke, i nogen grad, i høj grad, i
meget høj grad eller dækker fyldestgørende. Dette ville give et mere nuanceret billede. Den foreliggende
undersøgelses resurseramme ville dog ikke have været tilstrækkelig til at udføre denne type vurdering.
25

27. Datagrundlaget, to rapporter fra Gartner og IDS Scheer, er ikke meget bredt. Derudover er både Gartner og IDS
Scheer konsulenthuse, som er stærkt involveret på EA området. Derfor kan der være tvivl om rapporternes
objektivitet.
Failure is an option … | 18-05-2011
26