hvorfor fejler ea

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

[email protected]

1

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Failure is an option …

Eller: Hvorfor fejler Enterprise Arkitektur initiativer?

Indhold

INDLEDNING ............................................................................................................ 2 1

1.1 PROBLEMFORMULERING ........................................................................................ 3

1.2 METODE .......................................................................................................... 3

1.3 AFGRÆNSNING ................................................................................................... 3

BEGREBSAFKLARING ................................................................................................... 4 2

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

TEORI .................................................................................................................... 6 3

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

ANALYSE ................................................................................................................. 8 4

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

KONKLUSION ......................................................................................................... 25 5

PERSPEKTIVERING OG METODEKRITIK ............................................................................ 25 6

BIBLIOGRAFI ........................................................................................................... 27 7

BILAG A ................................................................................................................ 29 8

BILAG B ................................................................................................................ 34 9

BILAG C ................................................................................................................ 35 10

BILAG D................................................................................................................ 39 11

BILAG E ................................................................................................................ 43 12

2

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

FIGUR 1-1: GARTNER HYPE CYCLE FOR EA 2010

Indledning 1Udviklingen 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.

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.

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?

3

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

”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

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.

4

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

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.

Begrebsafklaring 2

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, organization, enterprise

Organizing logic, organizational structures, current and future states

Requirements, strategy Processes, business, operating model

Technical infrastructure, technology perspective

E A = S + B + T

Enterprise Architecture is the idea of integrating strategy, business and technology 2-1 EA = S + B + T (BERNARD, 2005)

5

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Governance

EA

rammeværk

EA

Metode

EA

Artefakter

EA værktøjer &

repository

EA

Best Practices

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 ti lgang, 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

sikkert at tilgå og benytte lageret.

I sin definition af EA fastslår Bernard, at EA både er en

dokumentations metode og et management program. For

at leve op til denne definition skal EA være del af en

overordnet governance struktur.

Governance definerer Bernard som

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

6

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Teori 3Der 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

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.3 OIO EA

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-2 TOGAF 9 ADM

3-1BERNARDS EA3 CUBE

3-3 OIO EA METODEN

7

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

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 Forandringsledelse

Hvad går forandringsprojekter i

virksomheder typisk ud på?

For at komme fra nutidens situation, tit

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

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

psykologisk. Når utilfredsheden med den nuværende situation, ønsket om

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.

Én metode at håndtere store forandringsprojekter på er blevet grundlagt af

John Kotter. Kotter konstaterer at 70 procent af alle forandrings initiativer

fejler. For at tackle problemerne, forslår Kotter en 8-trinsproces (Kotter,

1996)

Lighederne mellem en forandringsproces og et EA initiativ er meget

tydelige:

EA AS-IS situation Den brændende platform

EA TO-BE situation Fremtidens vision

EA Management Plan Vejen frem

Bernards EA3 cube og dens EA TO-BE

status, gør det meget anskueligt, hvilke

emner EA fokuserer på og hvilke områder

der derfor skal regnes med forandringer af:

strategier, processer, teknologier, mål m.v.

Et skoleeksempel på forandring.

1 Change Equation (Gleicher, Beckhard, Harris): D * V * F > R: Dissatisfaction * Vision * First, concrete steps > Resistance

Hvad skal forandres?

mission vision mål strategi

opgaver medarbejder organisation

teknologi processer

Den brændende platform Fremtid - Vision

Forøg presset og følelsen af

nødvendighed

Etabler den ledende koalition. Er

nøgleinteressenterne enige?

Får vision og strategi gjort klar.

HVORFOR skal vi?

KOMMUNIKER visionen – fortæl

historien

GØR DET – og styrk

medarbejdernes kompetence

Skab synlige resultater også på

kort sigt

Konsolider forbedringer og

fasthold forandringsforløbet

Implementer ny procedurer i

organisationens kultur

3-5 BERNARDS EA3 CUBE

3-4 KOTTERS OTTE TRIN

8

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Analyse 4

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 en effektiv leder

Skal erstattes med nogen, som har bløde kompetencer som entusiasme, lidenskab og kan kommunikere.

G2 Utilstrækkelig forståelse og understøttelse hos nøgleinteressenter uden for EA teamet.

EA skal sælges til topledelsen først. Fokus på uddannelse og kommunikation.

G3 Forretningen er ikke involveret. IT og forretningsmål er ikke tilpasset hinanden

Enterprise arkitekter skal involvere sig i forretningen og, 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 EA realiseres for sent.

Skab sammenhæng med forretningen og udvikle TO-BE status først

G6 EA gruppen gør det meste af arbejdet alene (uden input fra forretningen) => resulterer i manglende buy-in hos forretningen

EA processen skal ledes og ikke påtvinges. Virtuelle teams

G7 Værdien af EA måles og kommunikeres ikke, fordi den kun er synlig indirekte.

Vis og kommuniker alle succeshistorier inklusive værdimålinger

G8 Kassetænkning … arkitektur for proces, information, teknik og løsning for forretningsenheder modelleres uafhængigt og uden hensyn til integration og interoperabilitet.

Fokus på sammenhæng mellem forretningsenheder

G9 EA governance introduceres for sent i forløbet

Skal udvikles samtidig med indholdet

G10 Der bruges ikke tid nok på kommunikation Udvikling og iværksættelse af en kommunikations plan som er tilpasset til modtagerne

9

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

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 and policy” del af EA programmet

Klare mål fra begyndelsen, forventningsafstemning, få EA 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 af EA værktøjet

Sørg for at forretningssiden er involveret i udvalget af værktøjet.

10

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

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.

EA Chefarkitekten kender til EA, men er ikke en effektiv leder

Utilstrækkelig forståelse og understøttelse hos nøgleinteressenter uden for EA teamet.

Forretningen er ikke involveret. IT og forretningsmål er ikke tilpasset hinanden

Domain Level arkitektur

AS-IS status dokumenteres først. Værdien af EA realiseres for sent.

EA gruppen gør det meste af arbejdet alene (uden input fra forretningen) => resulterer i manglende buy-in hos forretningen

Værdien af EA måles og kommunikeres ikke, fordi den kun er synlig indirekte.

Kassetænkning … arkitektur for proces, information, teknik og løsning for forretningsenheder modelleres uafhængigt og uden hensyn til integration og interoperabilitet.

EA governance introduceres for sent i forløbet

Der bruges ikke tid nok på kommunikation

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.

Forøg presset og følelsen af

nødvendighed

Etabler den ledende koalition. Er

nøgleinteressenterne enige?

Får vision og strategi gjort klar.

HVORFOR skal vi?

KOMMUNIKER visionen – fortæl

historien

GØR DET – og styrk

medarbejdernes kompetence

Skab synlige resultater også på

kort sigt

Konsolider forbedringer og

fasthold forandringsforløbet

Implementer ny procedurer i

organisationens kultur

11

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

4.2 EA metodernes håndtering af r isici i EA init iativer

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.

2 (Bernard, 2005), Chapter3: The value and risk of creating an Enterprise Architecture

12

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Problem Håndteres af Aktivitet Vurdering

G1

EA Chefarkitekten kender til EA men er ikke en effektiv leder

EA3 trin 1

Etablering af EA programmet og udnævnelse af Chef Arkitekten tilstrækkelige resurser (budget, personale m.v.) og myndighed. Dannelse af EA team som består af EA arkitekter og forskellige nøgleinteressenter

Trinet tager hensyn til finansielle risici (sørge for finansiel stabilitet) og sørger for ledelsesopbakning fra begyndelsen

G2

Utilstrækkelig forståelse og understøttelse hos nøgleinteressenter udenfor EA teamet.

EA3 trin 4

Udvikling af EA kommunikationsplan og sørge for buy- in, fokus på ikke-tekniske nøglepersoner og EA slutbruger. Inkluder eksempler på hvordan EA skaber værdi, sørg for at dokumentationen er tilgængelig for alle

EA3 trin20

Frigiv regelmæssige opdateringer af EA management planen, Kommuniker hvordan EA har reduceret omkostninger, forbedret alignment etc.

Trinet fokuserer på risikoen vedr. manglende acceptanse.

Fokus på kommunikation af værdien som EA skaber

Bernards metode tager således hensyn til de nogle af de problemer som Gartner (Gartner, 2009) nævner

G3

Forretningen er ikke involveret. IT og forretningsmål er ikke tilpasset

EA3 trin 1


EA teamet består af arkitekter og andre nøgleinteressenter

G4


EA3 trin 7

Identifikation af EA komponenter som skal dokumenteres

G5


EA3 trin 11

Evaluering om eksisterende dokumentation kan bruges i EA programmet => AS-IS

EA3 trin 11

Skab dokumentation af EA komponenter som mangler => AS-IS

Bernards metode begynder med dokumentationen af AS-IS situationen.

G6


EA3 trin 5

Valg af EA dokumentations rammeværk med input fra EA team og nøgleinteressenter.

13

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

G7


EA3 trin 4

Udvikling af EA kommunikationsplan og sørge for buy-in, fokus på ikke-tekniske nøglepersoner og EA slutbruger. Inkludere eksempler på hvordan EA skaber værdi, sørge for at dokumentationen er tilgængelig for alle

Trinet fokuserer på risikoen vedr. manglende accept.

Bernards metode tager således hensyn til de nogle af de problemer, som Gartner (Gartner, 2009) nævner

G8


EA3 trin 6

Identifikation af brancher/segmenter (“Lines of business”) og delte aktiviteter (“crosscuttings”)

Crosscuttings sørger for forbindelsen mellem forskellige enheder af en organisation

G9


EA3 trin 3

Etablering af EA governance som også opretter en forbindelse med forretningens andre managementprocesser (strategi planlægning, projekt management, sikkerhed, personaleplanlægning)

G10


EA3 trin 4

Udvikling af EA kommunikationsplan og sørge for buy- in, fokus på ikke-tekniske nøglepersoner og EA slutbruger. Inkludere eksempler på hvordan EA skaber værdi, sørge 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.

Trinet fokuserer på risikoen vedr. manglende acceptanse.

Bernards metode tager således hensyn til de nogle af de problemer som Gartner (Gartner, 2009) nævner

S1

Kun i 40 % af alle virksomheder er ”objectives and policy” del af EA programmet

EA3 trin 3

Etablering af EA governance som også opretter en forbindelse med forretningens andre managementprocesser (strategi planlægning, projekt management, sikkerhed, personaleplanlægning)

S2

Svært at skabe forbindelsen mellem EA og forretningsstrategi (EA + BPM)

14

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

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

EA3 trin 1


Trinet tager hensyn til finansielle risici (sørge for finansiel stabilitet) og sørger for ledelsesopbakning fra begyndelsen

S6

Manglende engagement hos nøgleinteressenter

EA3 trin 4

Udvikling af EA kommunikationsplan og sørge for buy-in, fokus på ikke-tekniske nøglepersoner og EA slutbruger. Inkludere eksempler på hvordan EA skaber værdi, sørge for at dokumentationen er tilgængelig for alle

Trinet fokuserer på risikoen vedr. manglende accept.

Bernards metode tager således hensyn til de nogle af de problemer som IDS Scheer (Jonathan Broer, Sven Roeleven, IDS Scheer, 2009) nævner

S7

Finansielle og politiske spørgsmål forpurrer EA projektet

EA3 trin 1


Trinet tager hensyn til finansielle risici (sørge for finansiel stabilitet) og søger for ledelsesopbakning fra begyndelsen

S8

CIO eller IT manager har ansvaret for udvalg af EA værktøjet

EA3 trin 5

Valg af EA dokumentations rammeværk med input fra EA team og nøgleinteressenter.

EA3 trin 8

Valg af dokumentationsmetoden (Chef 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)

15

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

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, 2009, s. kapitel 52) beskrives EA manageren som ekspert på områder som leadership, teamwork, interpersonal, communication, 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.”

TOGAFs beskriver omfattende, hvilke kompetencer der forventes fra de forskellige roller I et EA program, bl.a. EA manageren

G2


Et af målene i TOGAF ADM Phase A er:

”define the relevant stakeholders, and their concerns

and objectives” (The Open Group, 2009, s. TOGAF Step 7.4.2). Processen beskrives yderlige i ”Steps in the stakeholder management process” (The Open Group, 2009, s. TOGAF 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”

16

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11


G3


ADM Phase B: Business Architecture

“the development of a Business Architecture to support an agreed Architecture Vision”

Det er her en forbindelse mellem TOGAF EA og et BPM program kunne skabes. Forbindelsen som TOGAF skaber i dette trin er dog meget teknisk fokuseret.

G4


ADM Phase C: Information Systems Architectures og Phase D: Technology Architecture

G5


ADM Phase B: Business Architecture, Phase C: Information Systems Architectures, Phase D: Technology Architecture

Nøgleudsagner : “knowledge of the Business Architecture is a prerequisite for architecture work in any other domain”

Faserne B, C og D går ud fra at der først skabes ”Baseline Descriptions” (=> AS-IS) af de forskellige arkitekturer

G6


G7


ADM Phase A : 7.4.9 Define the Target Architecture Value Propositions and KPIs

“Review and agree the value propositions with the sponsors and stakeholders concerned “

“Define the performance metrics and measures to be built into the enterprise architecture to meet the business needs”

TOGAF tager højde for AT det skal gøres, men er ikke meget detaljeret vedr. HVORDAN dette kunne gøres.

17

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11


G8


TOGAF afsnit: 29. Interoperability Requirements

In the Architecture Vision (Phase A), the nature and security considerations of the information and service exchanges are first revealed within the business scenarios.

In the Business Architecture (Phase B), the 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.

Interoperabilitet er en integreret del af alle faser I TOGAF ADM

G9


ADM Preliminary Phase

[…] major output of this phase is a framework for architecture governance. [..] i.e., what type of 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

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,

TOGAF 9 kræver at governance kommer på plads allerede i opstartsfasen

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap06.html#tag_06_04_02


18

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11


G10


ADM Stakeholder Management og TOGAF 36.2.12 Communications Plan

“Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location”

TOGAF gør vigtigheden af kommunikationen tydeligt.

S1


S2



S3


ADM Stakeholder Management

CxO level

“This stakeholder group is interested in the high-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

S5


ADM Preliminary Phase sørger for “sponsor’s sign-off to proceed”

ADM Phase E: Opportunities & Solutions

TOGAF afsnit 32. Capability-Based Planning

At politiske eller finansielle spørgsmål forpurrer projektet kan aldrig udelukkes. ”Salgsfasen” er afgørende. TOGAFs tiltag på dette område er dog ret begrænset

S6


ADM Preliminary Phase og TOGAF afsnit 42. Tools for Architecture Development beskriver valget af EA værktøjer

Det er evalueringen som beskrives, men IKKE hvem der skal være med til valget

19

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

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)


G1


OIO definerer en række arkitektroller bl.a. Enterprise Arkitekten. Personen skal have indflydelse på virksomhedens beslutninger og taler både forretningssprog og teknikersprog.

De forventede kompetencer vises i et profil

Ledelses og Kommunikationskompetencer er ikke vurderet som at være særlig vigtige … teknologi, analyse og strategi kompetence vurderes at være vigtigere

G2


OIO EA trin A3.5: Vision, mål, strategier

”vigtigt at indse, at man næppe skal forvente total enighed imellem forretningens beslutningstagere […] man laver en interessentanalyse”

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.

20

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11


G3


OIO EA trin A5. Vision, mål og strategier

”Trinet konsoliderer organisationens forretningsmæssige side vision, mål, strategier, og 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”

OIO tager højde for at konsolidere IT og forretning

Forretningssiden inkluderes

G4


G5


OIO EA Trin C1. Informationsarkitektur

OIO EA Trin C2. Applikationsarkitektur

OIO EA Trin C3. Servicearkitektur

OIO EA Trin C1. Teknologiarkitektur

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

OIO EA forudsætter an man udarbejder det nuværende stadie først … men fordi dette kan tager lang til anbefaler OIO at arbejdet kan foregå parallelt og at områder skal fravælges hvor muligt.

G6


OIO EA trin D2. Muligheder

” Det er vigtigt at spørge eksplicit ind til forbedringsmuligheder, bredt i organisationen. Når man udvikler en enterprise arkitektur, kommer man typisk meget rundt i organisationen, og i kontakt med mange med gode ideer,der bare aldrig er nået frem til it-afdelingen.”

X1. Forretningsmæssige trends

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

21

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11


G7


OIO EA trin A5.1 Vision, mål, strategier samt kritiske succesfaktorer (KSF).

OIO EA trin A5.2 Metrikker (målepunkter) på de ovenstående – fx KPIs (key performance indicators).

G8


G9


OIO EA trin A2 EA governance strategi

- økonomiske, organisatoriske og andre rammer - 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.

Governance introduceres tideligt i forløbet

G10


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.

S1


”Verifikation og justering af denne konsolidering, typisk gennem en workshop. Topledelsen bør være repræsenteret her, således at den konsensus der opnås afspejler et balanceret syn på forretningen, og dermed forankrer EA indsatsen

22

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11


S2


OIO EA trin A5. Vision, mål og strategier

”Trinet konsoliderer organisationens forretningsmæssige side vision, mål, strategier, og 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 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

OIO tager højde for at konsolidere IT og forretning

Forretningssiden inkluderes !

S3


S4


OIO EA trin D2. Muligheder

”Trinet identificerer projekter der måske ikke er strategiske og en del af entreprise arkitekturen, men som er taktiske og på kort tid og uden en stor indsats kan give en gevinst i form af effektivitet, besparelser og større kvalitet.”

OIO EA går med dette trin efter quick wins …

S5


A2. EA governance strategi

”Trinet sigter mod, fra start, at opstille rammer der skal sikre at enterprise arkitekturen kan realiseres, at nøgle-aktører tages i ed og involveres …”

http://ea.oio.dk/arkitekturmetode/trin/x-tekniske-og-forretningsmessige-trends/resolveuid/f3a8fcf5f5f08c178b30503161c57532

23

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11


S6


OIO EA trin A2

EA governance strategi der udføres evt. en interessentanalyse: overblik over 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

CIO eller IT manager har ansvaret for valg af EA værktøjet

OIO EA A4. EA projekt charter

OIO giver ingen anbefalinger om hvem der vælger værktøjer eller hvordan dette skal gøres

24

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

4.3 Resultater

Fejl! Henvisningskilde ikke fundet. 3 viser EA

metodernes evne til at adressere de problemer, som i praksis

ofte fører med sig at EA programmer fejler.

4.3.1 EA3

Bernards EA3 metode har en meget bred dækning af de fleste

problemer som EA oplever i praksis og som Gartner og IDS

Scheer nævner i deres rapporter.

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,

ikke giver meget hjælp til, hvordan man skal gøre det.

Et eksempel: Bernard skriver i EA3 om, at kommunikation er

vigtigt, men når man undersøger man EA rollerne og deres

ansvar, har ingen i teamet særlige kommunikationsopgaver.

4.3.2 TOGAF ADM

TOGAF håndterer ikke problemer i gennemførelsen af EA

programmer, som Gartner og IDS Scheer nævner i deres

rapporter, i samme udstrækning som de to andre metoder.

Forfatteren skal dog medgive at TOGAF metoden, på de

områder den adresserer, er meget udspecificeret. Især

vigtigheden af EA chefarkitektens kompetenceprofil og

håndtering af nøgleinteressenterne skal her fremhæves.

4.3.3 OIO EA

OIO EA dækker ligeledes over en stor række af EA

virkelighedens problemer. Forfatter ser OIO EA som meget

nemt forståelig metode. OIO EA har ikke fokus nok på

chefarkitektens leder kompetence og forandrings aspektet

som der er i EA programmer.

3 For problemer som der ikke kunne klart svares på om metoderne adresserer dem, er svaret blank (de hvide felter)

Problem EA3 TOGAF

ADM

OIO

EA

G1 + + -

G2 + + +

G3 + - +

G4 + +

G5 - - +/-

G6 + +

G7 + +/- +

G8 + +

G9 + + +

G10 + + +

S1 + +

S2 - +

S3 +

S4 + +

S5 + - +

S6 + - +

S7 +

S8 + -

25

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Konklusion 5

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.

Perspektivering og Metodekritik 6Et 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.

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.

26

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

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.

27

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Bibliografi 7Arkitekturroller i digitaliseringsarbejdet. (20. 4 2009). Hentet fra OIO Arkitekturguiden:

http://ea.oio.dk/arkitekter/roller

Bernard, S. A. (2005). An introduction to Enterprise Architecture-2nd edition. Author House.

Eijpe, R., Laar, C., Rosenberg, A., Kuhlmann, S., & von Rosing, M. (2011). The holistic approach: Combining

BPM with Value and Performance Management, Enterprise Architecture and Governance. I Rosenberg,

Chase, Omar, Taylor, & v. Rosing, Applying Real-World BPM in an SAP environment (s. 105-119). Boston,

MA: Gallileo Press Inc.

Gartner. (2009). Predicts 2010: Major Changes in Store for Enterprise.

Gartner. (2009). Ten Enterprise Architecture Pitfalls. Gartner’s Enterprise Architecture Summits 2009. Egham:

Gartner.

Gartner. (5. 8 2010). Gartner's Enterprise Architecture Hype Cycle Reveals Two Generations of Enterprise Architecture .

Hentede 13. 5 2011 fra Gartner Newsroom: http://www.gartner.com/it/page.jsp?id=1417513

IT og Telestyrelsen. (10. 1 2007). Del 2: Overblik over EA metoden. Hentet fra OIO Arkitekturguiden:

http://ea.oio.dk/arkitekturmetode/introduktion/del-2-overblik-over-oio-enterprise-arkitektur-

metoden

Jensen, C. T., Cline, O., & Owen, M. (2011). Combining Business Process Management and Enterprise Architecture for

Better Business Outcomes. IBM.

Jonathan Broer, Sven Roeleven, IDS Scheer. (6 2009). Why two thirds of Enterprise Architecture projects fail. Hentede

12. 5 2011 fra http://its.a-cci.com/doc/EA_-_Roeleven_Broer_-

_Enterprise_Architecture_Projects_Fail_-_AEP_en.pdf

Kappelman, L. A. (2010). Enterprise Architecture: Creating Information Age Organizations. I L. A. Kappelman,

The SIM Guide to Enterprise. New York City: CRC Press.

Koch, C. (1. 3 2005). A New Blueprint For The Enterprise. Hentede 13. 5 2011 fra CIO magasin.

Kotter, J. (1996). Leading Change: Why Transformation Efforts Fail. Boston, MA: Harvard Business Press.

Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as a strategy. Boston, MA: Harvard

Business Press.

The Open Group. (2009). 50. Architecture Governanve. I TOGAF version 9 Enterprise Edition. The Open Group.

The Open Group. (2009). 52. Architecture Skills framework. Hentede 16. 5 2011 fra TOGAF version 9 Enterprise

Edition: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap52.html

The Open Group. (2009). Stakeholder Management. Hentede 16. 5 2011 fra TOGAF version 9 Enterprise Edition:

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html

Wagter, R., van den Berg, M., Luijpers, J., & van Steenbergen, M. (2005). Dynamic Enterprise Architecture - How to

make it work. Hoboken, NJ: John Wiley&Sons, Inc.

Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), s. 276 -

292.

28

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Zachman, J. A. (May/June 2001). You can't "cost-justify" architecture. DataToKnowledge Newsletter, Vol. 29, No. 3

.

Zachman, J. A. (June 2007). EIMInsight MAGAZINE CURRENT ISSUE. Hentede 15. 5 2011 fra EIMinstitute.org:

http://www.eiminstitute.org/library/eimi-archives/volume-1-issue-4-june-2007-edition/the-

framework-for-enterprise-architecture-background-description-and-utility

29

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Bilag A 8

TOGAF Architecture Development Method

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.

All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities.

Phases within the ADM are as follows:

The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the business directive for a new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles.

The steps within the Preliminary phase are as follows:

Scope the Enterprise Organizations Impacted

Confirm Governance and Support Frameworks

Define and Establish Enterprise Architecture Team and Organization

Identify and Establish Architecture Principles

Select and Tailor Architecture Framework(s)

Implement Architecture Tools

Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.

The steps in Phase A are as follows:

Establish the Architecture Project

Identify Stakeholders, Concerns, and Business Requirements

Confirm and Elaborate Business Goals, Business Drivers, and Constraints

Evaluate Business Capabilities

Assess Readiness for Business Transformation

Define Scope

Confirm and Elaborate Architecture Principles, including Business Principles

Develop Architecture Vision

Define the Target Architecture Value Propositions and KPIs

Identify the Business Transformation Risks and Mitigation Activities

Develop Enterprise Architecture Plans and Statement of Architecture Work; Secure Approval

Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision.

The steps in Phase B are as follows:

Select Reference Models, Viewpoints, and Tools







http://eapad.dk/togaf9/part2-adm/phase-a-architecture-vision/#tag_08_04_01











http://eapad.dk/togaf9/part2-adm/phase-b-business-architecture/#tag_09_04_01

30

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Develop Baseline Business Architecture

Description

Develop Target Business Architecture

Description

Perform Gap Analysis

Define Roadmap Components

Resolve Impacts Across the Architecture

Landscape

Conduct Formal Stakeholder Review

Finalize the Business Architecture

Create Architecture Definition Document

Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.

The steps in Phase C (Data Architecture) are as follows:


Develop Baseline Data Architecture Description

Develop Target Data Architecture Description



Resolve Impacts Across the Architecture Landscape


Finalize the Data Architecture


The steps in Phase C (Application Architecture) are as follows:


Develop Baseline Application Architecture Description

Develop Target Application Architecture Description





Finalize the Application Architecture


Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project.

The steps in Phase D are as follows:


Develop Baseline Technology Architecture Description

Develop Target Technology Architecture Description












http://eapad.dk/togaf9/part2-adm/phase-c-information-systems-architectures-data-architecture/#tag_11_04_01









http://eapad.dk/togaf9/part2-adm/phase-c-information-systems-architectures-application-architecture/#tag_12_04_01









http://eapad.dk/togaf9/part2-adm/phase-d-technology-architecture/#tag_13_04_01



31

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11





Finalize the Technology Architecture


Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.

The steps in Phase E are as follows:

Determine/Confirm Key Corporate Change Attributes

Determine Business Constraints for Implementation

Review and Consolidate Gap Analysis Results from Phases B to D

Review IT Requirements from a Functional Perspective

Consolidate and Reconcile Interoperability Requirements

Refine and Validate Dependencies

Confirm Readiness and Risk for Business Transformation

Formulate High-Level Implementation and Migration Strategy

Identify and Group Major Work Packages

Identify Transition Architectures

Create Portfolio and Project Charters and Update the Architectures

Phase F: Migration Planning addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan.

The steps in Phase F are as follows:

Confirm Management Framework Interactions for Implementation and Migration Plan

Assign a Business Value to Each Project

Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles

Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document

Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan

Establish the Architecture Evolution Cycle and Document Lessons Learned

Phase G: Implementation Governance provides an architectural oversight of the implementation.

The steps in Phase G are as follows:

Confirm Scope and Priorities for Deployment with Development Management

Identify Deployment Resources and Skills

Guide Development of Solutions Deployment

Perform Enterprise Architecture Compliance Reviews

Implement Business and IT Operations

Perform Post-Implementation Review and Close the Implementation







http://eapad.dk/togaf9/part2-adm/phase-e-opportunities-solutions/#tag_14_04_01











http://eapad.dk/togaf9/part2-adm/phase-f-migration-planning/#tag_15_04_01







http://eapad.dk/togaf9/part2-adm/phase-g-implementation-governance/#tag_16_04_01






32

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.

The steps in Phase H are as follows:

Establish Value Realization Process

Deploy Monitoring Tools

Manage Risks

Provide Analysis for Architecture Change Management

Develop Change Requirements to Meet Performance Targets

Manage Governance Process

Activate the Process to Implement Change

Requirements Management examines the process of managing architecture requirements throughout the ADM.

Step Requirements Management Steps ADM Phase Steps

1 Identify/document requirements - use business scenarios, or an analogous technique

2 Baseline requirements:

a. Determine priorities arising from current phase of ADM

b. Confirm stakeholder buy-in to resultant priorities c. Record requirements priorities and place in

requirements repository

3 Monitor baseline requirements

4 Identify changed requirements:

a. Remove or re-assess priorities b. Add requirements and re-assess priorities c. Modify existing requirements

5 Identify changed requirements and record priorities:

a. Identify changed requirements and ensure the requirements are prioritized by the architect(s) responsible for the current phase, and by the relevant stakeholders

b. Record new priorities c. Ensure that any conflicts are identified and

managed through the phases to a successful conclusion and prioritization

d. Generate Requirements Impact Statement (see 36.2.18 Requirements Impact Assessment) for steering the architecture team

Notes

Changed requirements can come in through any route. To ensure that the requirements are properly assessed and prioritized, this process needs to direct the ADM phases and record the decisions related to the

http://eapad.dk/togaf9/part2-adm/phase-h-architecture-change-management/#tag_17_04_01








33

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

requirements. The Requirements Management phase needs to determine stakeholder satisfaction with the decisions. Where there is dissatisfaction, the phase remains accountable to ensure the resolution of the issues and determine next steps.

6 a. Assess impact of changed requirements on current (active) phase

b. Assess impact of changed requirements on previous phases

c. Determine whether to implement change, or defer to later ADM cycle; if decision is to implement, assess timescale for change management implementation

d. Issue Requirements Impact Statement, Version n+1

7 Implement requirements arising from Phase H

The architecture can be changed through its lifecycle by the Architecture Change Management phase (Phase H). The requirements management process ensures that new or changing requirements that are derived from Phase H are managed accordingly.

8 Update the requirements repository with information relating to the changes requested, including stakeholder views affected

9 Implement change in the current phase

10 Assess and revise gap analysis for past phases

The gap analysis in the ADM Phases B through D identifies the gaps between Baseline and Target Architectures. Certain types of gap can give rise to gap requirements.

The ADM describes two kinds of gap:

Something that is present in the baseline, but not in the target (i.e., eliminated - by accident or design)

Something not in the baseline, but present in the target (i.e., new)

A "gap requirement" is anything that has been eliminated by accident, and therefore requires a change to the Target Architecture.

If the gap analysis generates gap requirements, then this step will ensure that they are addressed, documented, and recorded in the requirements repository, and that the Target Architecture is revised accordingly.

34

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Bilag B 9TOGAF Enterprise Architecture Role and Skill Definitions (The Open Group, 2009)

http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/52_skills1_generic.png





35

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Bilag C 10

24 TOGAF Stakeholder Management (The Open Group, 2009)

24.1 Introduction

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 benefits of successful Stakeholder Management are that:

The most powerful stakeholders can be identified early and their input can then be used to shape the architecture; this ensures their support and improves the quality of the models produced.

Support from the more powerful stakeholders will help the engagement win more resource, thus making the architecture engagement more likely to succeed.

By communicating with stakeholders early and frequently, the architecture team can ensure that they fully understand the architecture process, and the benefits of enterprise architecture; this means they can support the architecture team more actively when necessary.

The architecture engagement team can more effectively anticipate likely reactions to the architecture models and reports, and can build into the plan the actions that will be needed to capitalize on positive reaction whilst avoiding or addressing any negative reactions.

It is essential in any initiative to identify the individuals and groups within the organization who will contribute to the development of the architecture, identify those that will gain and those that will lose from its introduction, and then develop a strategy for dealing with them.

24.2 Approach to Stakeholder Management

Stakeholder analysis should be used during Phase A (Architecture Vision) to identify the key players in the engagement, and also be updated throughout each phase; different stakeholders may be uncovered as the engagement progresses through into Opportunities & Solutions, Migration Planning, and Architecture Change Management.

Complex architectures are extremely hard to manage, not only in terms of the architecture development process itself, but also in terms of obtaining agreement from the large numbers of stakeholders touched by it.

For example, just as a building architect will create wiring diagrams, floor plans, and elevations to describe different facets of a building to its different stakeholders (electricians, owners, planning officials), so an enterprise architect must create different views of the business, information system, and technology architecture for the stakeholders who have concerns related to these aspects.

TOGAF specifically identifies this issue throughout the ADM through the following concepts (as defined in 35.1 Basic Concepts):

Stakeholders Concerns Views Viewpoints

24.3 Steps in the Stakeholder Management Process

The following sections detail recommended Stakeholder Management activity.

24.3.1 Identify Stakeholders

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html#tag_35_01

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html#tag_35_01

36

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Identify the key stakeholders of the enterprise architecture.

The first task is to brainstorm who the main enterprise architecture stakeholders are. As part of this, think of all the people who are affected by it, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion.

It might include senior executives, project organization roles, client organization roles, system developers, alliance partners, suppliers, IT operations, customers, etc.

When identifying stakeholders there is a danger of concentrating too heavily on the formal structure of an organization as the basis for identification. Informal stakeholder groups may be just as powerful and influential as the formal ones.

Most individuals will belong to more than one stakeholder group, and these groups tend to arise as a result of specific events.

Look at who is impacted by the enterprise architecture project:

Who gains and who loses from this change? Who controls change management of processes? Who designs new systems? Who will make the decisions? Who procures IT systems and who decides what to buy? Who controls resources? Who has specialist skills the project needs? Who has influence?

In particular, influencers need to be identified. These will be well respected and moving up, participate in important meetings and committees (look at meeting minutes), know what's going on in the company, be valued by their peers and superiors, and not necessarily be in any formal position of power.

Although stakeholders may be both organizations and people, ultimately the enterprise architecture team will need to communicate with people. It is the correct individual stakeholders within a stakeholder organization that need to be formally identified.

It is possible to distinguish five broad categories of stakeholder, as shown in Categories of Stakeholder .

http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/24_stakeholders.png



http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html#tagfcjh_32


37

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Figure 24-1: Categories of Stakeholder

Consider both the Visible team - those obviously associated with the project/change - and the Invisible team - those who must make a real contribution to the project/change for it to be successful but who are not obviously associated with it (e.g., providers of support services).

24.3.2 Classify Stakeholder Positions

Develop a good understanding of the most important stakeholders and record this analysis for reference and refresh during the project. An example stakeholder analysis is shown in Example Stakeholder Analysis .

Stakeholder Group

Stakeholder Ability To

Disrupt

Current Under-

standing

Required Under-

standing

Current Commit-

ment

Required Commit-<BR<MENT<

b>

Required Support

CIO John Smith H M H L M H

CFO Jeff Brown M M M L M M

Table: Example Stakeholder Analysis

It is also important to assess the readiness of each stakeholder to behave in a supportive manner (i.e., demonstrate commitment to the enterprise architecture initiative).

This can be done by asking a series of questions:

Is that person ready to change direction and begin moving towards the Target Architecture? If so, how ready?

Is that person capable of being a credible advocate or agent of the proposed enterprise architecture initiative? If so, how capable?

How involved is the individual in the enterprise architecture initiative? Are they simply an interested observer, or do they need to be involved in the details?

Has that person made a contractual commitment to the development of the enterprise architecture, and its role in the governance of the development of the organization?

Then, for each person whose commitment is critical to ensure success, make a judgment as to their current level of commitment and the desired future level of commitment.

24.3.3 Determine Stakeholder Management Approach

The previous steps identified a long list of people and organizations that are affected by the enterprise architecture project.

Some of these may have the power either to block or advance. Some may be interested in what the enterprise architecture initiative is doing; others may not care. This step enables the team to easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters of the initiative.

Work out stakeholder power, influence, and interest, so as to focus the enterprise architecture engagement on the key individuals. These can be mapped onto a power/interest matrix, which also indicates the strategy to adopt for engaging with them. Stakeholder Power Grid shows an example power grid matrix.

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html#tagtcjh_3

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html#tagfcjh_33

38

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Figure 24-2: Stakeholder Power Grid

24.3.4 Tailor Engagement Deliverables

Identify viewpoints, matrices, and views that the architecture engagement needs to produce and validate with each stakeholder group to deliver an effective architecture model.

It is important to pay particular attention to stakeholder interests by defining specific viewpoints, matrices, and views of the enterprise architecture model. This enables the architecture to be communicated to, and understood by, all the stakeholders, and enables them to verify that the enterprise architecture initiative will address their concerns.

24.4 Template Stakeholder Map

The following table provides an example stakeholder map for a TOGAF architecture project.

Stakeholder Involvement

Cla

ss

Relevant Viewpoints

CxO (Corporate Functions); e.g., CEO, CFO, CIO, COO

This stakeholder group is interested in the high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business.

KE

EP

SAT

ISFI

ED

Business Footprint

Goal/Objective/ Service Model

Organization Chart

http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/24_stakeholder_grid.png




39

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Bilag D 11

Overblik over EA metoden (IT og Telestyrelsen, 2007)

OIO EA metoden fokuserer på trinene indenfor de fem centrale aktiviteter (de der er markeret med blåviolet). Altså trinene A1-E3. Trinene X1-X2 samt Y1-Y5 indgår i et samspil med OIO EA metoden, og er ligeledes beskrevet. De vil dog normalt udføres af andre end de enterprise arkitektur-ansvarlige, med undtagelse af trin Y3 EA governance, der er central for vedligeholdelse af arkitekturen.

Om OIO EA metoden er der følgende vigtige punkter at bemærke sig:

1. Som også anført i håndbogen: Det en løbende, iterativ proces at udvikle og vedligeholde en Enterprise Arkitektur.

2. OIO EA er en metode, ikke et arkitekturrammeværk. Man kan for eksempel ikke sammenligne den med Zachman Framework, som er et rammeværk, ikke en metode. Output produceret efter OIO EA metoden kan naturligvis klassificeres efter OIO EA rammeværket, Zachman eller andre rammeværker.

3. De enkelte trin udføres ikke i en fastlagt rækkefølge. Nummereringen antyder én, der ofte kan være hensigtsmæssig (idet output fra nogle af trinene er input til andre). Men man kan for eksempel sagtens udføre B5 og B6 før man laver B1-B4. Ligeledes vil man ofte udføre dokumentationen af den nuværende arkitektur i trin C1-C4 i parallel med B-trinene, for så, når begge foreligger, designe den fremtidige teknik-arkitektur – også i trin C1-C4.

4. Ligeledes kan man (og vil ofte) udføre flere trin i parallel – for eksempel ”nuværende arkitektur” delen af trin C1-C4 paralleliseres ofte. Selv hvor man ikke gør dette, vil man kunne opleve at et trin kan give anledning til tilbageløb, hvor man modificerer output fra tidligere trin.

http://ea.oio.dk/arkitekturmetode/introduktion/resolveuid/89b86dcefd5e387f25b2ddfacd47cc32

40

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

5. Man udfører kun sjældent alle trin i OIO EA metoden, man tilpasser den efter behovet. Man kan eksempelvis vælge at fokusere på infrastruktur-konsolidering, hvor for eksempel dele af C1 og hele C4 så vil være centrale. Eller man kan for eksempel vælge at fokusere på proces-optimering, hvor så B3/B4 samt C2/C3 vil være nøgletrin at gennemføre. Kapitel 3 eksemplificerer hvordan OIO EA med fordel kan anvendes i et givet scenarium. Separat (i et dokument og online) beskrives andre hyppige scenarier.

6. Inden for hvert trin udfører man ligeledes ikke altid alle leverancer. For eksempel indeholder C1. Informationsarkitektur to hoveddele: C1.1 beskriver den logiske datamodel – som en udvidelse og detaljering af B1’s forretningsobjektmodel. C1.2-3 beskriver lokationer og dataflows imellem fysiske databaser der implementer B1/C1.1. Man vil kunne lave disse to ret uafhængigt af hinanden, begge baseret på input fra B1.

7. Det er ikke et mål i sig selv at lave Enterprise Arkitektur arbejde. Heraf følger at man med fordel kan fokusere på de områder der med mindst nødvendig indsats giver de mest rigtige svar til hvordan teknologi skal anvendes til at opnå de ønskede forretningsmål.

8. EA arkitekten er en gennemgående aktør i alle trin. Ikke nødvendigvis som den drivende kræft i alle trin, men for at sikre konsistens på tværs, og identificere synergimuligheder hvor relevant. I tilfælde af inkonsistens mellem leverancer (eksempelvis at den foreslåede teknologiarkitektur ikke understøtter den fremtidige applikationsarkitektur) skal EA arkitekten søge at løse dette. Typisk vil man samle de arkitekter der har udarbejdet leverancerne, og se om ikke der kan afdækkes en brugbar løsning.

Når man påbegynder et EA projekt, der sigter mod at etablere eller modificere en Enterprise Arkitektur, fastlægger man altså den specifikke brug af OIO EA metoden, sådan som punkt 3.-6. angiver.

OIO Enterprise Arkitektur metodetrin (IT og Telestyrelsen, 2007)

A. Strategi

A1. EA-relaterede udfordringer

A2. EA governance strategi

A3. EA metodegrundlag

A4. Projekt charter

A5. Vision, mål og strategier

A6. It-principper

B. Forretning

B1. Forretningsobjekter

B2. Lokationer/organisation

B3. Forretningsservices

B4. Forretningsprocesser

B5. Use cases

B6. Workflows

C. Teknik

C1. Informationsarkitektur

C2. Applikationsarkitektur

C3. Servicearkitektur

C4. Teknologiarkitektur

D. Gap analyse

D1. Restriktioner

D2. Muligheder

http://ea.oio.dk/arkitekturmetode/introduktion/resolveuid/b7bb4f4c0c167aac6f446011ac4a5c23

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/310edc41aac7366fdce01a8f326fc4ea

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/ab75d5ee2e5b56303eef718102df610e

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/01086bdd0aa8893cb555c850d9434d1b

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/2d35917eb8d7a62f86fb6cfb6c4dc99a

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/8add369c49b8ffcae8eae5033c561935

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/f3a8fcf5f5f08c178b30503161c57532

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/efafbaf44b9fa09728a461af13c3fb25

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/8bdab77113015d73f66654dd5a5f76f7

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/7da6a03526de71d777c67f06a5fbfb52

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/a023aa5d4a2ebd84f113b99dff3f4ce0

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/486023f9b7baab783d40f0e08a7ea80d

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/433fcb16fec298f1859bf63e3957173f

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/18354a416eb47894649dd62088f8244c

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/6036f8ae378fd0f29b476b9557721ccb

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/33df28ccadd7c290c78b0d0f8c67fadc

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/1018980e640ea5054af7969bda2f13bf

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/e2bc0ce15733069752d54bf8b0c059ec

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/ed44886a39fdc9870da09fe211fc73c2

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/f42d353372625a7d950a06283d56aa3a

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/660cbc990976781e3e0611c1d854b362

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/282177f6e64e0a7fdfa998c743460b70

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/16e387957c93409fafebdf64ae346ba2

41

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

D3. Gap analyse

E. Forandring

E1. Migreringsstrategi

E2. Migreringsplan

E3. Konsekvensanalyse

X. Tekniske og forretningsmæssige trends

X1. Forretningsmæssige trends

X2. Tekniske trends

Y. Principper og styring

Y1. Driftssituation

Y2. Budget og ressourcestyring

Y3. EA governance

Y4. Lovmæssige bindinger

Y5. Kontrakt og aftaleforhold

Arkitekturroller i digitaliseringsarbejdet

Der er mange forskellige roller i et digitaliseringsprojekt. Her er en række af de centrale roller beskrevet i forhold

til arkitekturdiscipliner. Rollerne er desuden mappet til eksempler på de roller og titler, som anvendes i mange

organisationer.

Kært barn har mange navne. Vi har defineret seks arkitektroller, som understøtter OIO EA metoden.

Mange organisationer - specielt offentlige - har slet ikke nogen medarbejdere med med en titel hvor ordet arkitekt indgår i relation til it og digitalisering. Typisk hedder det fx it-chef, konsulent, projektleder eller udvikler. I andre organisationer - specielt leverandørvirksomheder - har man fx it-arkitekter, solutionarkitekter eller sikkerhedsarkitekter.

Man kunne således sagtens have defineret andre roller end de seks vi beskriver her. Men vores formål har været at skabe en kobling til metoderammen. Ovennævnte eksempler vil typisk håndtere en eller flere af de seks roller vi har defineret. Omvendt har hver af de seks roller vi har defineret et medansvar for fx at en løsning hænger sammen og at sikkerheden håndteres ordentligt.

Enterprise arkitekten

Enterprise arkitektens ansvar er udviklingen af en enterprise arkitektur, forankring af denne i virksomhedens ledelse og sørge for at denne blive fulgt i praksis. Enterprise arkitekten arbejder proaktivt og med en planlægningshorisont 2-4 år ud i fremtiden, hvor virksomhedens forretningsstrategi påvirker enterprise arkitektur.

Enterprise arkitekten deltager typisk i virksomhedens it-governance processer, og har et medansvar for at virksomhedens it-budget investeres optimalt.

I organisationer hvor man ikke anvender selve termen som jobtitel varetages rollen måske af erfarne medarbejdere med titler som , digitaliseringschef, it-chef, chefkonsulent, specialkonsulent, konsulent eller måske projektchef, projektleder.

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/f22ea92b56971de3536cdbcdcf639f95

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/9b5a25b631aec3714152d3c5716ba8de

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/af0883287e1ce3d93e90b0f3f3fc18b6

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/4d3572a4d95f0a496d53ff40e91ad301

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/dd3f18699259dfd7fc0a8f37200ea75b

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/dbce45e0b09f1d2f28b22d2acdd6df6c

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/6c7d42abe86a3f8f095ddc3d7ae81c94

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/24f41578af22ccd8a96393d9d64033a2

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/4f581a9fd0f4c8cc37d201f498f799d4

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/b4754b10c4670e337a983e238315c821

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/017c40e825196545f8f597f84fd46f93

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/7b28e8acf7bf659e0a0510264e6c4572

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/2161ea64c70f6b883235626fdf0ae0de

http://ea.oio.dk/arkitekturmetode/trin/resolveuid/1ee5234240dc7586aeaa5cbe3e3bdc1b

42

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

Forretningsarkitekt

Forretningsarkitektens har modeller og teknikker der anvendes i forretningsmodellering, og kan arbejde med forretningsstrategier og – processer.

Vedkommende har ofte et godt kendskab til et forretningsområde – f.eks. socialsektoren – og er ansvarlig for at kunne tilvejebringe grundlag for at træffe beslutninger, der vedrører virksomhedens strategi og arkitektur og som sikrer at systemer har sammenhæng på tværs (således at man undgår ”siloer”).

I organisationer hvor man ikke anvender selve termen som jobtitel varetages rollen måske af erfarne medarbejdere med titler som projektleder, chefkonsulent eller specialkonsulent, men det kan også være specialister med alle mulige andre titler. Det karakterisktiske er evnen til at kombinere en domæneviden med kompetencen til at definere og modellere processer, tjenester, begreber mv.

Informationsarkitekt

Informationsarkitekten er ansvarlig for modellering af de data og informationer, der anvendes. Informationsarkitektens primære fokus er information. Igennem et tæt samarbejde med forretningsarkitekten og applikationsarkitekten, sørger han/hun for at data modelleres og anvendes konsistent på tværs af virksomheden.

I organisationer hvor man ikke anvender selve termen som jobtitel varetages rollen måske af medarbejdere med mange forskellige titler, fx informationsmedarbejder, bibliotektkar, redaktør, specialkonsulent, mv. men det kan også være specialister med alle mulige andre titler. Det kan være folk fra forretningen eller udviklere der kommer fra it-afdelingen. Det karakterisktiske er evnen til at kombinere en forretningsmæssig domæneviden med kompetencen til at definere og modellere begreber, termer, indholdskategorier mv.

Applikationsarkitekt

Applikationsarkitekten er ansvarlig for design af applikationslandskab, integrationer og services i en organisation – typisk indenfor et forretningsområde (fx sundhed, social eller miljø) eller et tværgående domæne (fx økonomi-, HR- eller kontorapplikationer). Applikationsarkitekten samarbejder naturligvis tæt med alle de andre arkitektroller, men især med teknologiarkitekten for at sikre at applikationer og infrastruktur passer sammen. Applikationsarkitekten arbejder derudover også tæt sammen med informationsarkitekten for at sikre optimal udveksling og anvendelse af informationer.

I organisationer hvor man ikke anvender selve termen som jobtitel varetages rollen måske af medarbejdere med titler som fx udvikler, softwareudvikler eller solutionarkitekt.

Teknologiarkitekt

Teknologiarkitektens arbejdsområde omfatter ansvar for design af det centrale datacenter og/eller decentrale it-infrastrukturer og vedligeholdelse af infrastrukturen. Teknologiarkitekten er desuden ansvarlig for at applikationer og it-services på tværs af organisationen bliver vedligeholdt og opdateret – dvs. når der er f.eks. er ændringer eller opdateringer at sørge for, at disse bliver rullet konsistent ud.

I organisationer hvor man ikke anvender selve termen som jobtitel varetages rollen måske af medarbejdere med titler som fx it-chef, udvikler, eller solutionarkitekt.

Forandringsarkitekten

Forandringsarkitekten er ansvarlig for at løsninger bliver indført succesfuldt i organisationen. Forandringsarkitekten har ledererfaring, forstår organisationen godt, og er i stand til at håndtere politiske, organisatoriske og personlige konflikter. Forandringsarkitekten arbejder sammen med virksomhedens

43

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

forretningsledelse og personaleafdeling om at indføre nye arbejdsgange og jobbeskrivelser. Forandringsarkitekten er ikke nødvendigvis teknisk skolet.

Bilag E 12The Robbins-Gioia Survey (2001)

Robbins-Gioia, LLC, a provider of management consulting services located in Alexandria - Virginia, made a study over the perception by enterprises of their implementation of an E.R.P. (Enterprise Resource Planning) package.

Survey Scope

232 survey respondents spanning multiple industries including government, Information Technology, communications, financial, utilities, and healthcare.

A total of 36 % of the companies surveyed had, or were in the process of, implementing an ERP system.

Key Findings

51 % viewed their ERP implementation as unsuccessful

46 % of the participants noted that while their organization had an ERP system in place, or was implementing

a system, they did not feel their organization understood how to use the system to improve the way they

conduct business.

56 % of survey respondents noted their organization has a program management office (PMO) in place, and of

these respondents, only 36 % felt their ERP implementation was unsuccessful

Comments on the Robins-Gioia Survey

Project failure is not defined by objective criteria but by the perception of the respondents. The advantage of a perception is that it naturally integrates multiple aspects. Its obvious disadvantage is that it is inevitably partial: if the respondent has taken an active role in the project it will inevitably embellish the reality, whereas if the project has been "forced down his throat" he might cast a grimmer look at the project outcome.

The Conference Board Survey (2001)

Survey Scope

That survey interviewed executives at 117 companies that attempted ERP implementations

Key Findings

34 % were very “satisfied.”

58 % were “somewhat satisfied,”

8 % were unhappy with what they got.

40 % of the projects failed to achieve their business case within one year of going live

The companies that did achieve benefits said that achievement took six months longer than expected.

Implementation costs were found to average 25 % over budget,

Supports costs were underestimated for the year following implementation by an average of 20 %.

The KPMG Canada Survey (1997)

44

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

In April 1997, KPMG Canada sent a survey questionnaire focusing on IT project management issues to Canada's leading 1,450 public and private sector organizations. The main purpose was to outline the reasons behind the failure of Information Technology projects.

Survey Scope

Out of 1,450 questionnaires sent, 176 were analyzed. Of these, 61 % reported details on a failed IT project.

Key Findings

Over 61 % of the projects that were analyzed were deemed to have failed by the respondents. More than three quarters blew their schedules by 30% or more; more than half exceeded their budgets by a substantial margin. Considering that an estimated $25 billion is spent on IT application development in Canada annually, the survey data clearly indicate that unbudgeted IT project expenditures must run into the billions of dollars.

The Chaos Report (1995)

The Chaos Report is the first survey made by the Standish Group. This report is the landmark study of IT project failure. It is cited by everybody writing a paper or making a presentation were a reference is made of IT project failure.

Scope of the Study

The respondents to the Standish Group survey were IT executive managers. The sample includes large, medium, and small companies across major industry segments : banking, securities, manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal organizations. The total sample size was 365 respondents representing 8,380 applications. In addition, The Standish Group conducted focus groups and personal interviews to provide qualitative context for the survey results.

Key Findings

The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost over 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars in the United States alone.

Based on this research, The Standish Group estimates that in 1995 American companies and government agencies will spend $81 billion for canceled software projects. These same organizations will pay an additional $59 billion for software projects that will be completed, but will exceed their original time estimates. The Standish Group estimates that almost 80,000 projects were cancelled in 1995. Risk is always a factor when pushing the technology envelope, but many of these projects were as mundane as a drivers license database, a new accounting package, or an order entry system.

On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

This data may seem disheartening, and in fact it is, 48% of the IT executives in our research sample feel that there are more failures currently than just five years ago.

The OASIG Study (1995)

45

Fa

ilu

re is a

n o

pti

on

… |

18

-05

-20

11

This study has been undertaken under the auspices of OASIG, a Special Interest Group in the UK concerned with the Organizational Aspects of Information Technology.

Scope of the Study

Information was collected in 1995 in the United Kingdom from a sample of 45 experts employed primarily by Universities or Consultancies. On average they have each over 20 years personal experience representing a cumulative knowledge base of over 900 years. Their drew their opinion from a sample of approximately 14,000 user organizations. 31 of these interviewees (69%) include consultancy work as a major component of their work, and 27 (60%) include research; many do both. Their professional areas of expertise cover the domains of management, business, and social science. A small number of those interviewed have a background in engineering.

Data were collected by interviewing researchers and consultants using a semi-structured interview schedule. Some preparation was required by them. Each interview lasted, on average, around 1.5 to 2 hours, though some lasted considerably longer.

Key Findings

The IT project success rate quoted revolves around 20-30% based on its most optimistic interviews. Bottom line, at best, 7 out of 10 IT projects “fail” in some respect.

hvorfor fejler ea

Education