Failure is an option …Eller: Hvorfor fejler Enterprise Arkitektur initiativer?        MINIPROJEKT – ENTERPRISE ARCHITECTUR...
Failure is an option …                                                            Eller: Hvorfor fejler Enterprise Arkitek...
1 IndledningUdviklingen af nutidens forståelse af Enterprise Arkitektur som disciplin begyndte tilbage i 1987 med Zachmans...
”Closer business and IT alignment, a higher ROI and better business results aimed directly at the companies’ bottom line”....
Jeg forventer, at læseren har et overordnet kendskab til EA. EA rammeværkerne og metoder beskriver jeg kunkort. Rendyrkede...
2.2 Elementer af en Enterprise Arkitektur                                      De enkelte elementer af en EA tilgang forkl...
3 TeoriDer er udvalgt tre forskellige EA tilgange: Bernards EA3, OIO EA og TOGAFDer er udvalgt EA tilgange skal undersøges...
processen er iterativ er trinenes rækkefølge ikke lagt fast (se 0 ). Trinene kan også udføres parallelt.                  ...
4 Analyse4.1 EA problemer I praksis4.1.1 GartnerDen store amerikanske forsknings og rådgivningsvirksomhed, offentliggjorte...
4.1.2 IDS Scheer                                      IDS Scheer (Software AG) konkluderede baserende på en undersøgelse f...
4.1.3 Analyse af EA problemer i praksisDet er meget tydeligt, at der kun nævnes få EA faglige problemer, som f.eks. EA pro...
4.2 EA metodernes håndtering af risici i EA initiativer                                      4.2.1 Bernard EA3            ...
Problem                  Håndteres af Aktivitet                           Vurdering                         EA3 trin 1    ...
G7                        EA3 trin 4                                       Trinet fokuserer på risikoen vedr.             ...
S3Manglende bevidsthedom EA somforretningsaktivitet(asset)S4Iværksættelsen af EAtager mere tid endforventet, resultaterrea...
4.2.2 TOGAF ADM                                      TOGAF 9 indeholder i modsætning til EA3 ikke et eksplicit kapitel som...
Problem                    Aktivitet                                                 VurderingG3                         A...
Problem                   Aktivitet                                                Vurdering                              ...
Problem                   Aktivitet                                              VurderingG10                       ADM St...
4.2.3 OIO                                      Nævner OIO risici som EA3 eller TOGAF?                                     ...
Problem                   Aktivitet                                              VurderingG3                        OIO EA...
Problem                   Aktivitet                                               Vurdering                               ...
Problem                   Aktivitet                                                  VurderingS2                        OI...
Problem                    Aktivitet                                              Vurdering                               ...
4.3 ResultaterFejl! Henvisningskilde ikke fundet. 3 viser EA                           Problem          EA3        TOGAF  ...
5 Konklusion                                      Med denne undersøgelse prøver jeg at svare på, hvorfor mange EA programm...
Datagrundlaget, to rapporter fra Gartner og IDS Scheer, er ikke meget bredt. Derudover er både Gartner og IDSScheer konsul...
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Hvorfor Fejler EA
Upcoming SlideShare
Loading in...5
×

Hvorfor Fejler EA

1,307

Published on

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!

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,307
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
71
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Hvorfor Fejler EA"

  1. 1. Failure is an option …Eller: Hvorfor fejler Enterprise Arkitektur initiativer? MINIPROJEKT – ENTERPRISE ARCHITECTURE ITU KØBENHAVN – F2011 UNDERVISERE: JOHN GØTZE, SØREN ALAIN MORTENSEN 18. maj 2011 Claus Kortenkamp 010265 ckor@itu.dk
  2. 2. Failure is an option … Eller: Hvorfor fejler Enterprise Arkitektur initiativer? Indhold 1 INDLEDNING ............................................................................................................ 2 1.1 PROBLEMFORMULERING........................................................................................ 3 1.2 METODE .......................................................................................................... 3 1.3 AFGRÆNSNING ................................................................................................... 3 2 BEGREBSAFKLARING ................................................................................................... 4 2.1 ENTERPRISE ARKITEKTUR ...................................................................................... 4 2.2 ELEMENTER AF EN ENTERPRISE ARKITEKTUR ............................................................... 5 2.2.1 EA TILGANG, METODE OG RAMMEVÆRK .............................................................. 5 2.2.2 EA ARTEFAKTER, REPOSITORY OG GOVERNANCE ................................................... 5 2.2.3 EA BEST PRACTICES ....................................................................................... 5 3 TEORI .................................................................................................................... 6 3.1 BERNARD EA3 ................................................................................................... 6 3.2 TOGAF 9 ......................................................................................................... 6 3.3 OIO EA ........................................................................................................... 6 3.3.1 OIO EA METODE ......................................................................................... 6 3.4 FORANDRINGSLEDELSE ......................................................................................... 7 4 ANALYSE ................................................................................................................. 8 4.1 EA PROBLEMER I PRAKSIS ....................................................................................... 8 4.1.1 GARTNER .................................................................................................. 8 4.1.2 IDS SCHEER................................................................................................ 9 4.1.3 ANALYSE AF EA PROBLEMER I PRAKSIS ............................................................... 10 4.2 EA METODERNES HÅNDTERING AF RISICI I EA INITIATIVER .............................................. 11 4.2.1 BERNARD EA3 .......................................................................................... 11 4.2.2 TOGAF ADM .......................................................................................... 15 4.2.3 OIO ...................................................................................................... 19 4.3 RESULTATER ................................................................................................... 24 4.3.1 EA3 ....................................................................................................... 24 4.3.2 TOGAF ADM .......................................................................................... 24 4.3.3 OIO EA .................................................................................................. 24 5 KONKLUSION ......................................................................................................... 25 6 PERSPEKTIVERING OG METODEKRITIK ............................................................................ 25 7 BIBLIOGRAFI ........................................................................................................... 27Failure is an option … | 18-05-2011 8 BILAG A ................................................................................................................ 29 9 BILAG B ................................................................................................................ 34 10 BILAG C ................................................................................................................ 35 11 BILAG D................................................................................................................ 39 12 BILAG E ................................................................................................................ 43 1
  3. 3. 1 IndledningUdviklingen af nutidens forståelse af Enterprise Arkitektur som disciplin begyndte tilbage i 1987 med Zachmansartikel "A framework for information systems architecture" (Zachman J. A., 1987) og har siden resulteret italrige 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 typiskargumenter 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) konkluderedebaseret på en undersøgelse fra 2008(Jonathan Broer, Sven Roeleven, IDS Scheer,2009), at 66 procent af alle EA programmerikke lever op til forventningerne. F IGUR 1-1: G ARTNER H YPE C YCLE FOR EA 2010I juli 2010 vurderede Gartner den aktuelle modenhed af Enterprise Arkitektur (EA) og EA relaterede emner: EAog EA værktøjer befinder sig på nuværende tidspunkt i en fase af desillusionering, fordi EA udøvende ikkefokuserede nok på at integrere EA med forretningen. (Gartner, 2010)Samtidig viser Gartners undersøgelse at EA rammeværkernes betydning overvurderes betydeligt. Gartnervurderer derudover at det vil tager mere end 10 år inden EA rammeværker når at blive accepteret sommainstream.Allerede i 2005 skriver CIO magasinet om Enterprise Arkitektur: “CIOs go to great lengths to avoid using theterm with their business peers for fear of scaring, alienating or simply boring them to death” (Koch, 2005). MangeEA 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 cant "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 denikke 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 skaffeopbakning til Enterprise Arkitektur initiativer, hverken hos topledelsen eller potentielle interessenter. Failure is an option … | 18-05-2011Forventningen er, at forretningsværdien skal kunne demonstreres og kommunikeres ved at brugeforretningsledelsens sprog. Gartner forudser at 70 procent af alle succesrige EA initiativer i 2012 vil være ikke-ITbaserede 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 ellerARIS 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å ogmarkedsfører synergieffekten som integrationen af EA, BPM og/eller SOA lover at levere.Hvad er forventningerne til denne integration? 2
  4. 4. ”Closer business and IT alignment, a higher ROI and better business results aimed directly at the companies’ bottom line”. BPM og SOA har siden de dukkede op på business-IT scenen dog kæmpet med lignende problemer som EA: en stor del af projekterne fejler, det er vanskeligt at dokumentere forretningsværdien og det er derfor svært at få opbakning fra topledelsen. 1.1 Problemformulering Som C-level leder er der en stor chance for at man på et tidspunkt skal tager stilling til om et BPM, SOA og/eller EA program skal iværksættes. Spørgsmålet ”Hvad er egentlig risici med dette initiativ?” skal stilles og risiciene skal håndteres, dvs. at der skal iværksættes aktiviteter, som reducerer risikoens sandsynlighed eller som afbøder dens potentielle konsekvenser. Uden at påvise det matematisk, kan man gå ud fra at risikoen ikke bliver mindre, når initiativet kombinerer flere komplekse discipliner som EA, SOA og BPM. Dette kræver at man ændrer noget afgørende ved årsagerne til de problemer, man potentielt kan opleve med de enkelte discipliner. Når man starter et EA initiativ skal man være klar over at: Failure is an option! I denne opgave ønsker jeg derfor at undersøge spørgsmålet om Hvorfor fejler Enterprise Arkitektur (EA) projekter? Yderlige arbejdsspørgsmål som jeg undervejs ønsker at besvare i denne opgave, er 1. Hvilke årsager nævnes typisk som årsag til at EA initiativer fejler i praksis? 2. Hvilke risici nævnes der i de forskellige EA metoder? 3. Hvordan forslår EA metoderne at disse risici kan håndteres? 4. Matcher EA metodernes risikovurdering de problemer som opleves i praksis? 5. Kan problemer sammenlignes med de problemer som andre IT/forretnings initiativer oplever? 1.2 Metode For at sikre en fælles forståelse for de anvendte begreber, består opgavens første del af en begrebsafklaring. Der introduceres først metoder og teorier den foreliggende undersøgelse refererer til. Derefter formuleres et hovedspørgsmål og en række arbejdsspørgsmål som den foreliggende undersøgelse skal svare på. Opgaven udgangspunkt i en række af artikler, som forskellige forfattere, analyseinstitutter og konsulenthuse har offentliggjort, om årsager til problemer og/eller succes i EA initiativer. Der dannes en liste over de typiske problemer. For hver af de udvalgte EA metoder undersøges om og hvordan disse tager stilling til risikoen for at et EA initiativ fejler. Resultaterne samles i tabelform og sammenholdes derefter med rapporterne fra Gartners (Gartner, 2009) og IDSFailure is an option … | 18-05-2011 Scheer(Jonathan Broer, Sven Roeleven, IDS Scheer, 2009). På baggrund af disse undersøgelsesresultater, svares derefter på de undersøgelsens hovedspørgsmål. 1.3 Afgrænsning Når der i denne opgave tales om risici ved EA initiativer, menes risici, som kan påvirke forløbet af selve EA initiativet. Der undersøges ikke hvilke nye risici et EA initiativ muligvis introducerer i en virksomhed (f.eks. sikkerheds sårbarheder, øgede omkostninger for IT-løsninger eller introduktion af nye afhængigheder mellem forretningsenheder) Opgaven fokuserer på implementeringsmetode-delen af de forskellige EA varianter, og på hvordan metoden forholder sig til risiciene ved et EA initiativ. 3
  5. 5. Jeg forventer, at læseren har et overordnet kendskab til EA. EA rammeværkerne og metoder beskriver jeg kunkort. Rendyrkede EA rammeværker uden metodedel, som f.eks. Zachman, falder udenfor rammen af denneundersøgelse.Der forsøges ikke at vurdere hvilken EA metode der er den bedste. Valget af EA rammeværk og metode skal altidtilpasses den aktuelle virksomheds situation.Der undersøges ikke om integrationen af SOA, BPM og EA har synergieffekter. Mulige årsager for manglendesucces i BPM eller SOA programmer er ligeledes udenfor rammen af denne undersøgelse.Desuden forudsætter jeg, at læseren har grundlæggende kendskab om forandringsledelse.2 Begrebsafklaring2.1 Enterprise ArkitekturDer 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 standardizationrequirements 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, organizationalstructures, information flows and the technical infrastructure within an organization.” (Wagter, van den Berg,Luijpers, & van Steenbergen, 2005)“The analysis and documentation of an enterprise in its current and future states from an integrated strategy,business and technology perspective.” (Bernard, 2005)Nøglebegreberne i disse forskellige definitioner kan sammenfattes med Bernards meget prægnante formel:Company, Organizing logic, Requirements, strategy Processes, business, Technicalorganization, organizational operating model infrastructure,enterprise structures, current technology and future states perspective E A = S + B + T Enterprise Architecture is the idea of integrating strategy, business and technology2-1 EA = S + B + T (B ERNARD , 2005) Failure is an option … | 18-05-2011 4
  6. 6. 2.2 Elementer af en Enterprise Arkitektur De enkelte elementer af en EA tilgang forklares efterfølgende kun i det omfang der inden for rammerne af denne opgaven er behov for. Definitionen af de elementer en EA består af og som foreliggende undersøgelse benytter sig af, refererer til Scott A. Bernards bog om Enterprise Arkitektur (Bernard, 2005) 2.2.1 EA tilgang, metode og rammeværk Bernards definerer en EA tilgang som ”EA approach – a modeling framework and implementation methodology” (Bernard, 2005), dvs. At en EA tilgang består af 2 dele:  EA metoden og  EA rammeværket EA metode defineres heri med ”HOW the EA will be implemented and how documentation will be developed, archived and used; including the selection of a framework, modeling tools and on-line repository” (Bernard, 2005) men et EA rammeværk beskives som ”A structure for organizing information that defines the scope of the architecture (what the EA program will document) and how the areas of the architecture relate to each other.” (Bernard, 2005) 2.2.2 EA artefakter, repository og governance EA artefakter er alle de dokumenter som ”En EA artifact is a documentation product, such as text document, diagram, spreadsheet, briefing slides, or video clip. EA artifacts document EA components” (Bernard, 2005) EA repositoriet er stedet hvor EA artefakter lagres og gøres tilgængelige. ”A single place for the storage and retrieval of EA artifacts, that are created using EA software applications (tools)” (Bernard, 2005). Bernard understreger vigtigheden af at det er nemt og EA sikkert at tilgå og benytte lageret. Metode Governance I sin definition af EA fastslår Bernard, at EA både er en dokumentations metode og et management program. For EA EA EA Best Practices rammeværk Artefakter at leve op til denne definition skal EA være del af en overordnet governance struktur. EA værktøjer & Governance definerer Bernard somFailure is an option … | 18-05-2011 repository ”A group of policies, decision making procedures, and management processes that work together to enabler the effective planning and oversight over activities and resources” (Bernard, 2005) 2.2.3 EA best practices Ikke alle EA tilgange, nævner eksplicit at EA best practices skal være på plads. Men der kan siges at det er best practice, at EA best practices skal være med i hver EA tilgang. 5
  7. 7. 3 TeoriDer er udvalgt tre forskellige EA tilgange: Bernards EA3, OIO EA og TOGAFDer er udvalgt EA tilgange skal undersøges med hensyn til de formulerede spørgsmål. Metoderne blev udvalgtfordi 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 EA3Bernards EA3 metode består af i fire faser delt op i 20 trin:  Etablering af programmet  Valg af EA rammeværk og værktøj  Dokumentation af Enterprise Arkitekturen 3-1B ERNARDS EA3 CUBE  Brug og vedligeholdelse af Enterprise Arkitekturen3.2 TOGAF 9TOGAF 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 FrameworkADM er en metode til at udvikle en EA. ADM er delt op i en separatstart-up fase (preliminary) og ni efterfølgende faser (se billedet 3-2TOGAF 9 ADM) som gennemgås cyklisk og iterativ.En beskrivelse af disse faser er vedlagt Bilag ADerudover hjælper ADM Guidlines and Techniques yderlige medforklaringer på hvordan ADM kan tilpasses og anvendes. 3-2 TOGAF 9 ADM3.3 OIO EA Failure is an option … | 18-05-2011OIO- Offentlig Information Online- EA er en Enterprise ArkitekturGuide udarbejdet af IT og Telestyrelsen som led i et forløb, der skalkoordinere det tværoffentlige digitale samarbejde.OIO EA består af en metoderamme og en dokumentationsramme.3.3.1 OIO EA metodeMetoden er en procesorienteret metoderamme, som består af femaktiviteter, A-E, delt op i 22 trin. OIO understreger, at selv om 3-3 OIO EA METODEN 6
  8. 8. processen er iterativ er trinenes rækkefølge ikke lagt fast (se 0 ). Trinene kan også udføres parallelt. Ud over disse fem aktiviteter relaterer OIO også til to yderlige aktivitetsområder: Principper og Styring, og Tekniske og forretningsmæssige trends. I OIOs verden er det dog kun EA governance, som EA arkitekten har ansvaret for. 3.4 Forandringsledels e Hvad går forandringsprojekter i Hvad skal forandres? virksomheder typisk ud på? mission vision mål strategi For at komme fra nutidens situation, tit opgaver medarbejder organisation teknologi processer en situation som ikke længere er holdbar, en ”brændende platform”, skal virksomheden flyttes hen til en ønsket tilstand i fremtiden. For at nå til den Den brændende platform Fremtid - Vision fremtidige situation, skal noget ændres på et eller flere områder i en virksomhed, typiske emner er mission, vision, strategi, opgaver, organisation, processer, teknologi og medarbejdere. Hver forandring vil typisk møde modstand, enten materiel eller Forøg presset og følelsen af psykologisk. Når utilfredsheden med den nuværende situation, ønsket om nødvendighed at opnår en anden situation i fremtiden og viden om, hvordan man skal nå derhen er større en modstanden, kan forandringen lykkes 1. Etabler den ledende koalition. Er Én metode at håndtere store forandringsprojekter på er blevet grundlagt af nøgleinteressenterne enige? John Kotter. Kotter konstaterer at 70 procent af alle forandrings initiativer fejler. For at tackle problemerne, forslår Kotter en 8-trinsproces (Kotter, Får vision og strategi gjort klar. 1996) HVORFOR skal vi? Lighederne mellem en forandringsproces og et EA initiativ er meget tydelige: KOMMUNIKER visionen – fortæl historien  EA AS-IS situation  Den brændende platform  EA TO-BE situation  Fremtidens vision  EA Management Plan  Vejen frem GØR DET – og styrk medarbejdernes kompetence Bernards EA3 cube og dens EA TO-BE status, gør det meget anskueligt, hvilke Skab synlige resultater også på emner EA fokuserer på og hvilke områder kort sigt der derfor skal regnes med forandringer af: strategier, processer, teknologier, mål m.v. Konsolider forbedringer og Et skoleeksempel på forandring.Failure is an option … | 18-05-2011 fasthold forandringsforløbet 3-5 B ERNARDS EA3 C UBE Implementer ny procedurer i organisationens kultur 3-4 K OTTERS O TTE T RIN 1 Change Equation (Gleicher, Beckhard, Harris): D * V * F > R: Dissatisfaction * Vision * First, concrete steps > Resistance 7
  9. 9. 4 Analyse4.1 EA problemer I praksis4.1.1 GartnerDen store amerikanske forsknings og rådgivningsvirksomhed, offentliggjorte i 2009 en liste over de 10 størstefaldgruber ved et EA initiativ (Gartner, 2009) Problem LøsningG1 EA Chefarkitekten kender til EA, men er ikke Skal erstattes med nogen, som har bløde kompetencer en effektiv leder som entusiasme, lidenskab og kan kommunikere.G2 Utilstrækkelig forståelse og understøttelse EA skal sælges til topledelsen først. Fokus på uddannelse hos nøgleinteressenter uden for EA teamet. og kommunikation.G3 Forretningen er ikke involveret. IT og Enterprise arkitekter skal involvere sig i forretningen og, forretningsmål er ikke tilpasset hinanden sammen med andre kolleger, i forretningsarkitekturenG4 Domain Level arkitektur Holistisk EA best practice, som inkluderer forretnings-, informations- og løsningsarkitekturG5 AS-IS status dokumenteres først. Værdien af Skab sammenhæng med forretningen og udvikle TO-BE EA realiseres for sent. status førstG6 EA gruppen gør det meste af arbejdet alene EA processen skal ledes og ikke påtvinges. Virtuelle teams (uden input fra forretningen) => resulterer i manglende buy-in hos forretningenG7 Værdien af EA måles og kommunikeres ikke, Vis og kommuniker alle succeshistorier inklusive fordi den kun er synlig indirekte. værdimålingerG8 Kassetænkning … arkitektur for proces, Fokus på sammenhæng mellem forretningsenheder information, teknik og løsning for forretningsenheder modelleres uafhængigt og uden hensyn til integration og interoperabilitet.G9 EA governance introduceres for sent i Skal udvikles samtidig med indholdet forløbetG10 Der bruges ikke tid nok på kommunikation Udvikling og iværksættelse af en kommunikations plan som er tilpasset til modtagerne Failure is an option … | 18-05-2011 8
  10. 10. 4.1.2 IDS Scheer IDS Scheer (Software AG) konkluderede baserende på en undersøgelse fra 2008 (Jonathan Broer, Sven Roeleven, IDS Scheer, 2009), at 66 % af alle EA programmer ikke lever op til forventningerne. Problem Løsning S1 Kun i 40 % af alle virksomheder er ”objectives Klare mål fra begyndelsen, forventningsafstemning, få EA and policy” del af EA programmet governance på plads, have en standard projekt metode, S2 Svært at skabe forbindelsen mellem EA og forretningsstrategi (EA + BPM) S3 Manglende bevidsthed om EA som forretningsaktivitet (asset) S4 Iværksættelsen af EA tager mere tid end forventet, resultater realiseres senere S5 Manglende C-level understøttelse Udnævn en Chef Enterprise Arkitekt som kommunikerer med C-level ledelsen S6 Manglende engagement hos nøgleinteressenter Sørg for at forretningssiden er involveret S7 Finansielle og politiske spørgsmål forpurrer EA projektet S8 CIO eller IT manager har ansvaret for udvalg Sørg for at forretningssiden er involveret i udvalget af af EA værktøjet værktøjet.Failure is an option … | 18-05-2011 9
  11. 11. 4.1.3 Analyse af EA problemer i praksisDet 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 EABetragter man et EA program med forandringsledelsens briller, så viser der sig iøjnefaldende overensstemmelsermellem problemer med EA programmer i praksis og den måde hvordan store forandringsprocesser ifølge Kotters8-trins-model skal gennemføres.Dette gælder især for Gartners liste. Forøg presset og følelsen afEA Chefarkitekten kender til EA, men er ikke nødvendigheden effektiv lederUtilstrækkelig forståelse og understøttelse hos Etabler den ledende koalition. Ernøgleinteressenter uden for EA teamet. nøgleinteressenterne enige?Forretningen er ikke involveret. IT ogforretningsmål er ikke tilpasset hinanden Får vision og strategi gjort klar.Domain Level arkitektur HVORFOR skal vi?AS-IS status dokumenteres først. Værdien afEA realiseres for sent. KOMMUNIKER visionen – fortæl historienEA gruppen gør det meste af arbejdet alene(uden input fra forretningen) => resulterer imanglende buy-in hos forretningen GØR DET – og styrk medarbejdernes kompetenceVærdien af EA måles og kommunikeres ikke,fordi den kun er synlig indirekte.Kassetænkning … arkitektur for proces, Skab synlige resultater også på kort sigtinformation, teknik og løsning forforretningsenheder modelleres uafhængigt oguden hensyn til integration og Failure is an option … | 18-05-2011 Konsolider forbedringer oginteroperabilitet. fasthold forandringsforløbetEA governance introduceres for sent i forløbetDer bruges ikke tid nok på kommunikation Implementer ny procedurer i organisationens kulturMeget tyder på at allerede i startfasen af EA projekter kunne findes roden for de problemer som gør at EAprojekter fejler. Hvis ikke i opstartsfasen bliver tydeligt forklaret, hvor EA er et vigtigt initiativ, ognøgleinteressenterne ikke samles, mangler de bærende fundamentet til det videre EA forløb. 10
  12. 12. 4.2 EA metodernes håndtering af risici i EA initiativer 4.2.1 Bernard EA3 Bernard dedikerer et helt kapitel af sin bog til spørgsmålet om værdien og risici ved at skabe en Enterprise Arkitektur 2. Han nævner fem forskellige typer af risici som potentielt kunne påvirke et EA program:  Finansielle risici: Stort initial budget; senere besparelser på EA budgettet kan gøre EA informationerne værdiløse, hvis de ikke kan vedligeholdes.  Mangel på accept: store forandringer i strategi, forretning og teknologi, kan resultere i spændinger mellem forskellige nøgleinteressenter  Tab af nøglemedarbejdere: tab af uddannet EA personale fører til forsinkelser og øgede omkostninger  Forsinkelser: EA programmets tidsplan kan påvirkes fra forskellige sider, som kan resultere i at programmet afbrydes  Dokumentationsværktøjer: Det udvalgte værktøjet bestemmer hvor intuitive og informative EA programmets dokumenter er. Bernard beskriver derudover også nogle generelle foranstaltninger der kan reducere sandsynligheden for de nævne risici og for at reducere deres negative indvirkning:  Styrke ledelsesopbakning til EA programmet  Sørge for finansiel stabilitet  Lade være med at være den første som benytter et nyt værktøj  Sørge for at have uddannet backup personale til EA teamet  Benytte en detaljeret EA metode  Sørge for at program manager har grundlæggende kompetence vedrørende personaleledelse, budget, performance og håndtering af nøgleinteressenter Bernards EA3 metode består af i fire faser som er delt op i 20 trin. Disse trin analyseres og vurderes herefter med hensyn til de problemer i EA programmer som den foreliggende undersøgelse har fundet frem til i kapitel 04.1.Failure is an option … | 18-05-2011 2 (Bernard, 2005), Chapter3: The value and risk of creating an Enterprise Architecture11
  13. 13. Problem Håndteres af Aktivitet Vurdering EA3 trin 1 Trinet tager hensyn til finansielleG1 risici (sørge for finansiel stabilitet) og Etablering af EA programmet og udnævnelse af sørger for ledelsesopbakning fraEA Chefarkitekten Chef Arkitekten tilstrækkelige resurser begyndelsenkender til EA men er (budget, personale m.v.) og myndighed.ikke en effektiv leder Dannelse af EA team som består af EA arkitekter og forskellige nøgleinteressenterG2 EA3 trin 4 Trinet fokuserer på risikoen vedr. manglende acceptanse.Utilstrækkelig Udvikling af EA kommunikationsplan og sørgeforståelse og for buy- in, fokus på ikke-tekniske Fokus på kommunikation af værdienunderstøttelse hos nøglepersoner og EA slutbruger. Inkluder som EA skabernøgleinteressenter eksempler på hvordan EA skaber værdi, sørgudenfor EA teamet. for at dokumentationen er tilgængelig for alle Bernards metode tager således hensyn til de nogle af de problemer som EA3 trin20 Gartner (Gartner, 2009) nævner Frigiv regelmæssige opdateringer af EA management planen, Kommuniker hvordan EA har reduceret omkostninger, forbedret alignment etc.G3 EA3 trin 1 EA teamet består af arkitekter og andre nøgleinteressenterForretningen er ikke Etablering af EA programmet og udnævnelse afinvolveret. IT og Chef Arkitekten tilstrækkelige resurserforretningsmål er ikke (budget, personale m.v.) og myndighed.tilpasset Dannelse af EA team som består af EA arkitekter og forskellige nøgleinteressenterG4 EA3 trin 7Domain Level Identifikation af EA komponenter som skalarkitektur dokumenteresG5 EA3 trin 11 Bernards metode begynder med dokumentationen af AS-ISAS-IS status Evaluering om eksisterende dokumentation situationen.dokumenteres først. kan bruges i EA programmet => AS-ISVærdien af EArealiseres for sent. EA3 trin 11 Skab dokumentation af EA komponenter som mangler => AS-ISG6 EA3 trin 5 Failure is an option … | 18-05-2011EA gruppen gør det Valg af EA dokumentations rammeværk medmeste af arbejdet alene input fra EA team og nøgleinteressenter.(uden input fraforretningen) =>resulterer i manglendebuy-in hos forretningen 12
  14. 14. G7 EA3 trin 4 Trinet fokuserer på risikoen vedr. manglende accept. Værdien af EA måles Udvikling af EA kommunikationsplan og sørge og kommunikeres ikke, for buy-in, fokus på ikke-tekniske Bernards metode tager således hensyn fordi den kun er synlig nøglepersoner og EA slutbruger. Inkludere til de nogle af de problemer, som indirekte. eksempler på hvordan EA skaber værdi, sørge Gartner (Gartner, 2009) nævner for at dokumentationen er tilgængelig for alle G8 EA3 trin 6 Crosscuttings sørger for forbindelsen mellem forskellige enheder af en Kassetænkning … Identifikation af brancher/segmenter (“Lines of organisation arkitektur for proces, business”) og delte aktiviteter (“crosscuttings”) information, teknik og løsning for forretningsenheder modelleres uafhængigt og uden hensyn til integration og interoperabilitet. G9 EA3 trin 3 EA governance Etablering af EA governance som også opretter introduceres for sent i en forbindelse med forretningens andre forløbet managementprocesser (strategi planlægning, projekt management, sikkerhed, personaleplanlægning) G10 EA3 trin 4 Trinet fokuserer på risikoen vedr. manglende acceptanse. Der bruges ikke tid Udvikling af EA kommunikationsplan og sørge nok på kommunikation for buy- in, fokus på ikke-tekniske Bernards metode tager således hensyn nøglepersoner og EA slutbruger. Inkludere til de nogle af de problemer som eksempler på hvordan EA skaber værdi, sørge Gartner (Gartner, 2009) nævner for at dokumentationen er tilgængelig for alle EA3 trin20 Frigive regelmæssige opdateringer af EA management planen. Kommunikere hvordan EA har reduceret omkostninger, forbedret alignment etc. S1 EA3 trin 3 Kun i 40 % af alle Etablering af EA governance som også opretter virksomheder er en forbindelse med forretningens andre ”objectives and policy” managementprocesser (strategi planlægning,Failure is an option … | 18-05-2011 del af EA programmet projekt management, sikkerhed, personaleplanlægning) S2 Svært at skabe forbindelsen mellem EA og forretningsstrategi (EA + BPM)13
  15. 15. S3Manglende bevidsthedom EA somforretningsaktivitet(asset)S4Iværksættelsen af EAtager mere tid endforventet, resultaterrealiseres senereS5 EA3 trin 1 Trinet tager hensyn til finansielle risici (sørge for finansiel stabilitet) ogManglende C-level Etablering af EA programmet og udnævnelse af sørger for ledelsesopbakning fraunderstøttelse Chef Arkitekten tilstrækkelige resurser begyndelsen (budget, personale m.v.) og myndighed. Dannelse af EA team som består af EA arkitekter og forskellige nøgleinteressenterS6 EA3 trin 4 Trinet fokuserer på risikoen vedr. manglende accept.Manglende Udvikling af EA kommunikationsplan og sørgeengagement hos for buy-in, fokus på ikke-tekniske Bernards metode tager således hensynnøgleinteressenter nøglepersoner og EA slutbruger. Inkludere til de nogle af de problemer som IDS eksempler på hvordan EA skaber værdi, sørge Scheer (Jonathan Broer, Sven for at dokumentationen er tilgængelig for alle Roeleven, IDS Scheer, 2009) nævnerS7 EA3 trin 1 Trinet tager hensyn til finansielle risici (sørge for finansiel stabilitet) ogFinansielle og politiske Etablering af EA programmet og udnævnelse af søger for ledelsesopbakning fraspørgsmål forpurrer Chef Arkitekten tilstrækkelige resurser begyndelsenEA projektet (budget, personale m.v.) og myndighed. Dannelse af EA team som består af EA arkitekter og forskellige nøgleinteressenterS8 EA3 trin 5CIO eller IT manager Valg af EA dokumentations rammeværk medhar ansvaret for udvalg input fra EA team og nøgleinteressenter.af EA værktøjet EA3 trin 8 Valg af dokumentationsmetoden (Chef Failure is an option … | 18-05-2011 Arkitekt, EA team og flere nøgleinteressenter) EA3 trin 9 Valg af værktøj til EA dokumentation (Chef Arkitekt og EA team) EA3 trin 10 Valg og etablering af EA repository til dokumentation (Chef Arkitekt og EA team) 14
  16. 16. 4.2.2 TOGAF ADM TOGAF 9 indeholder i modsætning til EA3 ikke et eksplicit kapitel som henviser til risici ved gennemførslen af et EA program. Til gengæld tager TOGAF 9 speciel hensyn til emnerne håndtering af nøgleinteressenter og EA kompetencer. Stakeholder management: “Stakeholder Management is an important discipline that successful architecture practitioners can use to win support from others. It helps them ensure that their projects succeed where others fail.” (The Open Group, 2009) EA skills framework: “Skills frameworks provide a view of the competency levels required for specific roles. They define: the roles within a work area, the skills required by each role, the depth of knowledge required to fulfill the role successfully “ (The Open Group, 2009) Ud over trinene i ADM metoden, analyseres herefter også de 2 ovenstående emner med hensyn til de problemer i EA programmer som den foreliggende undersøgelse har fundet frem til i kapitel 0 Problem Aktivitet Vurdering G1 I ”skills framework” (The Open Group, TOGAFs beskriver omfattende, 2009, s. kapitel 52) beskrives EA manageren hvilke kompetencer der forventes EA Chefarkitekten som ekspert på områder som leadership, fra de forskellige roller I et EA kender til EA men er teamwork, interpersonal, communication, program, bl.a. EA manageren ikke en effektiv leder analyse, stakeholder management og risk management. En ekspert beskrives om person der har ”omfattende og væsentlig praktisk erfaring og anvendt viden om emnet” ”Communication and team building are key to the successful role of the enterprise architect. The mix of good technical skill and the ability to lead are crucial to the job. The enterprise architect should be viewed as a leader in the enterprise by the IT organization, the clients they serve, and management.” G2 Et af målene i TOGAF ADM Phase A er: Utilstrækkelig ”define the relevant stakeholders, and their concerns forståelse og and objectives” (The Open Group, 2009, s. understøttelse hos TOGAF Step 7.4.2). Processen beskrives nøgleinteressenter yderlige i ”Steps in the stakeholder management udenfor EA teamet. process” (The Open Group, 2009, s. TOGAFFailure is an option … | 18-05-2011 step 24.3). Nøgleudsagn er: “The most powerful stakeholders can be identified early […] this ensures their support and improves the quality of the models produced.” “… communicating […] early and frequently, […] they fully understand the architecture process, and the benefits of enterprise architecture; […]” “The […] team can more effectively anticipate likely reactions […], and […] plan the actions […] avoiding or addressing any negative reactions”15
  17. 17. Problem Aktivitet VurderingG3 ADM Phase B: Business Architecture Det er her en forbindelse mellem TOGAF EA og et BPM programForretningen er ikke “the development of a Business Architecture to kunne skabes. Forbindelsen sominvolveret. IT og support an agreed Architecture Vision” TOGAF skaber i dette trin er dogforretningsmål er ikke meget teknisk fokuseret.tilpasset hinandenG4 ADM Phase C: Information Systems Architectures og Phase D: TechnologyDomain Level ArchitecturearkitekturG5 ADM Phase B: Business Architecture, Faserne B, C og D går ud fra at der Phase C: Information Systems først skabes ”Baseline Descriptions”AS-IS status Architectures, Phase D: Technology (=> AS-IS) af de forskelligedokumenteres først. Architecture arkitekturerVærdien af EArealiseres for sent. Nøgleudsagner : “knowledge of the Business Architecture is a prerequisite for architecture work in any other domain”G6EA gruppen gør detmeste af arbejdet alene(uden input fraforretningen) =>resulterer i manglendebuy-in hos forretningenG7 ADM Phase A : 7.4.9 Define the Target TOGAF tager højde for AT det skal Architecture Value Propositions and KPIs gøres, men er ikke meget detaljeretVærdien af EA måles vedr. HVORDAN dette kunneog kommunikeres ikke, gøres. “Review and agree the value propositions with thefordi den kun er synlig sponsors and stakeholders concerned “indirekte. “Define the performance metrics and measures to be built into the enterprise architecture to meet the business needs” Failure is an option … | 18-05-2011 16
  18. 18. Problem Aktivitet Vurdering G8 TOGAF afsnit: 29. Interoperability Interoperabilitet er en integreret del Requirements af alle faser I TOGAF ADM Kassetænkning … arkitektur for proces, In the Architecture Vision (Phase A), the nature and information, teknik og security considerations of the information and service løsning for exchanges are first revealed within the business forretningsenheder scenarios. modelleres uafhængigt og uden hensyn til integration og In the Business Architecture (Phase B), the interoperabilitet. information and service exchanges are further defined in business terms. In the Data Architecture (Phase C), the content of the information exchanges are detailed using the corporate data and/or information exchange model. In the Application Architecture (Phase C), the way that the various applications are to share the information and services is specified. In the Technology Architecture (Phase D), the appropriate technical mechanisms to permit the information and service exchanges are specified. In Opportunities & Solutions (Phase E), the actual solutions (e.g., Commercial Off-The-Shelf (COTS) packages) are selected. In Migration Planning (Phase F), the interoperability is logically implemented. G9 ADM Preliminary Phase TOGAF 9 kræver at governance kommer på plads allerede i EA governance […] major output of this phase is a framework for opstartsfasen introduceres for sent i architecture governance. [..] i.e., what type of forløbet governance repository characteristics are going to be required, what relationships and status recording are necessary to ascertain which governance process (dispensation, compliance, take-on, retirement, etc.) has ownership of an architectural artifact.”  Confirm Governance and Support FrameworksFailure is an option … | 18-05-2011 Phase G: Implementation Governance “[…] the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance” I afsnit 50. Architecture Governance (The Open Group, 2009) leverer TOGAF uddybende forklaringer. Architecture Governance overvågnes og styres af et Architecture Board,17
  19. 19. Problem Aktivitet VurderingG10 ADM Stakeholder Management og TOGAF gør vigtigheden af TOGAF 36.2.12 Communications Plan kommunikationen tydeligt.Der bruges ikke tidnok på kommunikation “Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location”S1Kun i 40 % af allevirksomheder er”objectives and policy”del af EA programmetS2 Iværksættelsen af EA tager mere tid end forventet, resultater realiseres senereSvært at skabeforbindelsen mellemEA ogforretningsstrategi (EA+ BPM)S3 ADM Stakeholder ManagementManglende bevidsthed CxO levelom EA somforretningsaktivitet “This stakeholder group is interested in the high-(asset) level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business” KEEP SATISFIEDS4 TOGAF ADM afsnit 24. Stakeholder ManagementIværksættelsen af EAtager mere tid endforventet, resultaterrealiseres senereS5 ADM Preliminary Phase sørger for At politiske eller finansielle “sponsor’s sign-off to proceed” spørgsmål forpurrer projektet kanManglende C-level aldrig udelukkes. ”Salgsfasen” erunderstøttelse ADM Phase E: Opportunities & afgørende. TOGAFs tiltag på dette Solutions område er dog ret begrænset Failure is an option … | 18-05-2011 TOGAF afsnit 32. Capability-Based PlanningS6 ADM Preliminary Phase og TOGAF Det er evalueringen som beskrives, afsnit 42. Tools for Architecture men IKKE hvem der skal være medManglende Development beskriver valget af EA til valgetengagement hos værktøjernøgleinteressenter 18
  20. 20. 4.2.3 OIO Nævner OIO risici som EA3 eller TOGAF? I modsætning til Bernards EA3 metode, indeholder OIA EA ikke noget særlig kapitel vedrørende de risici som kunne true et EA initiativ. Der er heller ikke skrevet særlig meget om håndtering af nøgleinteressenter. OIO leverer dog en definition af forskellige arkitektroller og kompetenceprofiler (se 0) Problem Aktivitet Vurdering G1 OIO definerer en række arkitektroller bl.a. Ledelses og Enterprise Arkitekten. Personen skal have Kommunikationskompetencer er EA Chefarkitekten indflydelse på virksomhedens beslutninger og ikke vurderet som at være særlig kender til EA men er taler både forretningssprog og teknikersprog. vigtige … teknologi, analyse og ikke en effektiv leder strategi kompetence vurderes at De forventede kompetencer vises i et profil være vigtigere G2 OIO EA trin A3.5: Vision, mål, strategier Utilstrækkelig ”vigtigt at indse, at man næppe skal forvente total forståelse og enighed imellem forretningens beslutningstagere understøttelse hos […] man laver en interessentanalyse” nøgleinteressenter udenfor EA teamet. EA kommunikationsprocesser ”Barrieren […] er oftest at den ikke er kendt eller forstået.. Kommunikation kan indeholde: o EA forklaring: rollespecifikke og praktiske vejledninger (f.eks. hvad betyder arkitekturen for udvikleren o EA publikation: opdateret og lettilgængelig dokumentation (intranet, værktøjsintegration). En tilgængelig EA gør det lettere for andre at genbruge og forbedre den. o EA evangelisering; høj synlighed i organisationen. Omfatter præsentationer, kommunikation af succeshistorier, mv.Failure is an option … | 18-05-201119
  21. 21. Problem Aktivitet VurderingG3 OIO EA trin A5. Vision, mål og OIO tager højde for at konsolidere strategier IT og forretningForretningen er ikkeinvolveret. IT og ”Trinet konsoliderer organisationens Forretningssiden inkluderesforretningsmål er ikke forretningsmæssige side vision, mål, strategier, ogtilpasset hinanden analyserer hvilke kritiske succesfaktorer, der har afgørende betydning for at målene og strategierne realiseres. Der udvikles ingen nye mål og strategi i dette trin. Formålet er at sikre at efterfølgende EA aktiviteter er forankrede hos, og i overensstemmelse med forretningens behov.” OIO EA aktivitet B: Forretning ”Den fremtidige forretning beskrevet i mere operationelle termer”G4Domain LevelarkitekturG5 OIO EA Trin C1. Informationsarkitektur OIO EA forudsætter an man udarbejder det nuværende stadieAS-IS status OIO EA Trin C2. Applikationsarkitektur først … men fordi dette kan tagerdokumenteres først. lang til anbefaler OIO at arbejdetVærdien af EA OIO EA Trin C3. Servicearkitektur kan foregå parallelt og at områderrealiseres for sent. OIO EA Trin C1. Teknologiarkitektur skal fravælges hvor muligt. ”Trinet beskriver den nuværende og den fremtidige informationsarkitektur… ” ”Hvis man designer den fremtidige arkitektur indenfor et af de fire område, skal man dokumentere den nuværende indenfor dette område.”G6 OIO EA trin D2. MulighederEA gruppen gør det ” Det er vigtigt at spørge eksplicit ind tilmeste af arbejdet alene forbedringsmuligheder, bredt i organisationen. Når(uden input fra man udvikler en enterprise arkitektur, kommer manforretningen) => typisk meget rundt i organisationen, og i kontaktresulterer i manglende med mange med gode ideer,der bare aldrig er nåetbuy-in hos forretningen frem til it-afdelingen.” X1. Forretningsmæssige trends Failure is an option … | 18-05-2011 ”Ved interviews med forretningssiden bør der tages referat, og disse referater bør godkendes af de interviewede” EA Review Board (EARB) ”mødes ca. 8-12 gange årligt og træffer beslutninger vedr.arkitekturen, […] Medlemmerne bør rekrutteres fra forretning og teknik, og er personer med pondus i deres egen organisation, og et bredt udsyn.” 20
  22. 22. Problem Aktivitet Vurdering G7 OIO EA trin A5.1 Vision, mål, strategier samt kritiske succesfaktorer (KSF). Værdien af EA måles og kommunikeres ikke, OIO EA trin A5.2 Metrikker (målepunkter) fordi den kun er synlig på de ovenstående – fx KPIs (key indirekte. performance indicators). G8 Kassetænkning … arkitektur for proces, information, teknik og løsning for forretningsenheder modelleres uafhængigt og uden hensyn til integration og interoperabilitet. G9 OIO EA trin A2 EA governance strategi Governance introduceres tideligt i forløbet EA governance - økonomiske, organisatoriske og andre introduceres for sent i rammer forløbet - Identifikation af nøgle-aktører og beslutningstagere Dermed bliver disse involveret allerede fra start. Evt. interessentanalyse. overblik over alle interessenter i EA , deres respektive interesser, og planlægger involvering i EA forløbet. G10 OIO EA trin Y3 Der bruges ikke tid EA Governance, nok på kommunikation kommunikationsprocesser ”Barrieren […] er oftest at den ikke er kendt eller forstået.. Kommunikation kan indeholde: o EA forklaring: rollespecifikke og praktiske vejledninger (f.eks. hvad betyder arkitekturen for udvikleren o EA publikation: opdateret og lettilgængelig dokumentation (intranet, værktøjsintegration). En tilgængelig EA gør det lettere for andre at genbrugeFailure is an option … | 18-05-2011 og forbedre den. o EA evangelisering; høj synlighed i organisationen. Omfatter præsentationer, kommunikation af succeshistorier, mv. S1 Kun i 40 % af alle ”Verifikation og justering af denne konsolidering, virksomheder er typisk gennem en workshop. Topledelsen bør være ”objectives and policy” repræsenteret her, således at den konsensus der opnås del af EA programmet afspejler et balanceret syn på forretningen, og dermed forankrer EA indsatsen21
  23. 23. Problem Aktivitet VurderingS2 OIO EA trin A5. Vision, mål og OIO tager højde for at konsolidere strategier IT og forretningSvært at skabeforbindelsen mellem ”Trinet konsoliderer organisationens Forretningssiden inkluderes !EA og forretningsmæssige side vision, mål, strategier, ogforretningsstrategi (EA analyserer hvilke kritiske succesfaktorer, der har+ BPM) afgørende betydning for at målene og strategierne realiseres. Der udvikles ingen nye mål og strategi i dette trin. Formålet er at sikre at efterfølgende EA aktiviteter er forankrede hos, og i overensstemmelse med forretningens behov.” OIO EA trin X1: Forretningsmæssige trends ”indsamle information bredt, via både eksterne kilder (såsom rapporter fra analysebureauer) og via interne (visioner hos ledere). I A5 konsolideres disse og konkretiseres til forretningsstrategier, så der dannes et samlet billede af organisationens forretningsmæssige prioriteter” OIO EA aktivitet B: Forretning Den fremtidige forretning beskrevet i mere operationelle termerS3Manglende bevidsthedom EA somforretningsaktivitet(asset)S4 OIO EA trin D2. Muligheder OIO EA går med dette trin efter quick wins …Iværksættelsen af EA ”Trinet identificerer projekter der måske ikke ertager mere tid end strategiske og en del af entreprise arkitekturen, menforventet, resultater som er taktiske og på kort tid og uden en stor indsatsrealiseres senere kan give en gevinst i form af effektivitet, besparelser og større kvalitet.”S5 A2. EA governance strategiManglende C-level ”Trinet sigter mod, fra start, at opstille rammer derunderstøttelse skal sikre at enterprise arkitekturen kan realiseres, at nøgle-aktører tages i ed og involveres …” Failure is an option … | 18-05-2011 22
  24. 24. Problem Aktivitet Vurdering S6 OIO EA trin A2 Manglende EA governance strategi der udføres engagement hos evt. en interessentanalyse: overblik over nøgleinteressenter alle interessenter i EA , deres respektive interesser, og planlægger involvering i EA forløbet. OIO EA trin Y3 EA Governance, kommunikationsprocesser ”Barrieren […] er oftest at den ikke er kendt eller forstået.. Kommunikation kan indeholde: o EA forklaring: rollespecifikke og praktiske vejledninger (f.eks. hvad betyder arkitekturen for udvikleren o EA publikation: opdateret og lettilgængelig dokumentation (intranet, værktøjsintegration). En tilgængelig EA gør det lettere for andre at genbruge og forbedre den. o EA evangelisering; høj synlighed i organisationen. Omfatter præsentationer, kommunikation af succeshistorier, mv. S7 Finansielle og politiske spørgsmål forpurrer EA projektet S8 OIO EA A4. EA projekt charter OIO giver ingen anbefalinger om hvem der vælger værktøjer eller CIO eller IT manager hvordan dette skal gøres har ansvaret for valg af EA værktøjetFailure is an option … | 18-05-201123
  25. 25. 4.3 ResultaterFejl! Henvisningskilde ikke fundet. 3 viser EA Problem EA3 TOGAF OIOmetodernes evne til at adressere de problemer, som i praksisofte fører med sig at EA programmer fejler. ADM EA G1 + + -4.3.1 EA3Bernards EA3 metode har en meget bred dækning af de fleste G2 + + +problemer som EA oplever i praksis og som Gartner og IDS G3 + - +Scheer nævner i deres rapporter. G4 + +Der skal dog siges, at EA3 metoden, når den gør opmærksompå, at man som EA ansvarlig skal forholde sig til et problem, G5 - - +/-ikke giver meget hjælp til, hvordan man skal gøre det. G6 + +Et eksempel: Bernard skriver i EA3 om, at kommunikation er G7 + +/- +vigtigt, men når man undersøger man EA rollerne og deres G8 + +ansvar, har ingen i teamet særlige kommunikationsopgaver. G9 + + +4.3.2 TOGAF ADMTOGAF håndterer ikke problemer i gennemførelsen af EA G10 + + +programmer, som Gartner og IDS Scheer nævner i deres S1 + +rapporter, i samme udstrækning som de to andre metoder. S2 - +Forfatteren skal dog medgive at TOGAF metoden, på de S3 +områder den adresserer, er meget udspecificeret. Isærvigtigheden af EA chefarkitektens kompetenceprofil og S4 + +håndtering af nøgleinteressenterne skal her fremhæves. S5 + - +4.3.3 OIO EA S6 + - +OIO EA dækker ligeledes over en stor række af EA S7 +virkelighedens problemer. Forfatter ser OIO EA som megetnemt forståelig metode. OIO EA har ikke fokus nok på S8 + -chefarkitektens leder kompetence og forandrings aspektetsom der er i EA programmer. Failure is an option … | 18-05-20113 For problemer som der ikke kunne klart svares på om metoderne adresserer dem, er svaret blank (de hvide felter) 24
  26. 26. 5 Konklusion Med denne undersøgelse prøver jeg at svare på, hvorfor mange EA programmer fejler. Undersøgelser (Gartner, 2009) (Jonathan Broer, Sven Roeleven, IDS Scheer, 2009) nævner en række forskellige årsager. Foruden problemer som manglende kendskab til EA og manglende EA Governance, anføres dårlig ledelse, manglende kommunikation og manglende IT-business strategi alignment som hovedproblemer. De tre sidstnævnte er typiske i store forandringsprocesser. Kun én af de tre undersøgte metoder, EA3, gør direkte opmærksom på, at gennemførelsen af EA programmer generelt er truet af risici såsom finansielle risici, mangel på accept hos nøgleinteressenter, personaleproblemer og forsinkelser. Metoden, EA3, anbefaler samtidig nogle generelle aktiviteter, som skal modvirke disse risici, dog er aktiviteterne ikke udspecificeret. De andre metoder lægger vægt på håndtering af nøgleinteressenter og EA teamets kompetencer. Der er dog i det hele taget ikke meget fokus på de risici, som EA programmer er udsat for. Analysen af de udvalgte EA metoder viser, at alle tre i høj eller meget høj grad adresserer de problemer, som man oplever i EA programmernes virkelighed. Gartners undersøgelse positionerer det problem, at der bliver udnævnt EA chefarkitekter, som er dårlige ledere, som absolut hovedårsag til problemer i EA initiativer. Alle tre metoder tager stilling til EA chefarkitektens kompetencer. Kun TOGAF pointerer meget klart chefarkitektens betydning. EA3 behandler emnet overfladisk, mens OIO EA klart underprioriterer emnet. Hvorfor fejler EA projekter? De undersøgte metoder dækker i meget stort omfang de problemer, som analyserne finder frem til. Forandringsledelsens vinkel på EA projekter tager metoderne dog kun i meget begrænset omfang hensyn til. Denne undersøgelse konkluderer derfor, at en stor del af problemerne i EA projekter ikke skyldes EA metoderne, men manglende fokus på forandringsledelse i EA programmer. 6 Perspektivering og Metodekritik Et af arbejdsspørgsmålene har været om problemerne i forløbet af EA programmer kan sammenlignes med and IT-forretningsinitiativer. I Bilag E findes nogle eksempler på statistiker, som undersøger hvor tit IT projekter fejler. På grund af tidsmangel har jeg ikke undersøgt fænomenet nærmere men kort sagt kommer de anførte undersøgelser til det resultat at 40-70 procent af alle IT projekter fejler Begrænsede tidsresurser har begrænset omfanget af min undersøgelse, om de enkelte Enterprise Arkitektur metoder har et svar på problemerne i EA i praksis. Det begrænsede kendskab til de udvalgte metoder kan betyde, at enkelte positive eller negative vurderinger er blevet truffet på et for spinkelt grundlag. Især TOGAF er et meget omfattende værk, og det ville kræve meget mere tid at analysere denne metode fyldestgørende. Fordi metodernes oprindelse er forskellige, kan der sættes spørgsmålstegn ved, om det overhoved er rimeligt at sammenligne dem. Især OIO EA er jo en metode, som særlig tilpasset EA projekter i danske myndigheder.Failure is an option … | 18-05-2011 Vurderingen om en EA metode håndterer et bestemt problem eller ej er foregået uden klart definerede kriterier. Bare det faktum, at der findes informationer i den vurderede EA metode, som omhandler det pågældende problem, resulterede i, at metoden blev vurderet positiv. Selv om to metoder begge blev vurderet positiv, kan der være store forskel på metoderne. Man kunne overveje at vægte metodernes dækning af de undersøgte problemer, f.eks. metoden dækker ikke, i nogen grad, i høj grad, i meget høj grad eller dækker fyldestgørende. Dette ville give et mere nuanceret billede. Den foreliggende undersøgelses resurseramme ville dog ikke have været tilstrækkelig til at udføre denne type vurdering.25
  27. 27. Datagrundlaget, to rapporter fra Gartner og IDS Scheer, er ikke meget bredt. Derudover er både Gartner og IDSScheer konsulenthuse, som er stærkt involveret på EA området. Derfor kan der være tvivl om rapporternesobjektivitet. Failure is an option … | 18-05-2011 26

×