Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor jeg fortæller lidt om emner som IT-strategi, systemanalyse, udviklingsmetoder og modellering. Der er ikke tale om en struktureret gennemgang af disse emner fra ende til anden, men en samling af enkeltstående pointer, erfaringer og anbefalinger i mere eller mindre tilfældig rækkefølge. Podcastet Forsimpling kan findes på adressen: http://podcast.simplifysys.dk. Denne artikel er nummer 9 i serien, og den giver en kort introduktion til den enterprise arkitektur metode, der kaldes EA3 eller EA Cube. Overblik over EA3 EA3 er udviklet af Scott A. Bernard og beskrevet i hans bog An introduction to Enterprise Architecture, hvor han skriver om enterprise arkitektur i almindelighed, men med udgangspunkt i sin egen EA3-model. EA3 består af to dele. Dels selve rammeværktøjet, som er en struktur til dokumentation af forretningsstrategier, processer og systemarkitekturer, og dels en metode til at gennemføre ændringer i et forretningsområde. Rammeværktøjet EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Niveauer Den lodrette dimension i EA3-modellem repræsenterer de fem niveauer af dokumentation, som modellem skelner imellem: - 1 -
Mål og initiativer: Disse er de mest abstrakte dokumenter, som virksomhedens vision, mission og strategiske mål og initiativer Ydelser og produkter: Her beskrives virksomhedens generelle forretningsgange Data og Information: På tredje niveau dokumenteres virksomhedens data, dvs de ting, som har interesse for virksomheden Applikationer og systemer: Her beskrives virksomhedens implementerede IT-systemer Infrastruktur og netværk: På nederst niveau beskrives virksomhedens grundlæggende infrastruktur, dvs kommunikationsnetværk, udstyr, bygninger mv Niveauernes rækkefølge afspejler hvor konkrete emnerne er. Øverst er emnerne strategiske (mål). Længere nede bliver emnerne mere forretningsorienterede (ydelser og information). De nederste niveauer (data, applikationer og infrastruktur) omhandler teknologiske emner. Artefakter Den vandrette dimension repræsenterer de specifikke artefakter, man vælger at bruge til at beskrive de enkelte niveauer. De emner, der er vist yderst til venstre (sikkerhed, standard, medarbejdere) er særlige emner, der går på tværs af niveauerne, dvs at de skal dokumenteres på alle niveauer. Forretningsområder Dybden i EA3-modellen afspejler virksomhedens forskellige forretningsområder. Det betyder, at man i princippet skal udvikle separate arkitekturer for hvert forretningsområde i virksomheden. Scott Bernard hævder, at man skal holde øje med sammenfald af funktionalitet på tværs af forretningsområderne, men modellen lægger umiddelbart op til en adskillelse. Komponenter Endelig omtales de enkelte niveauer indenfor hvert forretningsområde som komponenter. Disse er uafhængige af hinanden og kan således i princippet udskiftes individuelt uden at det påvirker resten af arkitekturen. Metoden Sammen med EA3-modelen følger en metode i fire faser, der sikrer en struktureret tilgang til virksomhedens enterprise arkitektur. Metoden er generisk, så den kan bruges med andre rammeværktøjer end EA3. Fase 1: Etablering af programmet Fase 1 etablerer EA-holdet og rammerne for EA-programmet. Trin 1: Virksomhedens ledelse skal udpege en chefarkitekt og nødvendige ressourcer til at gennemføre EA-programmet. Trin 2: Chefarkitekten og EA-holdet skal herefter konkretisere metoden i forhold til virksomheden. Trin 3: Chefarkitekten definerer sammen med virksomhedens ledelse en EA-governance, der kan sikre en effektiv styring af EA-programmet i forhold til virksomhedens planlægning, - 2 -
politik og ledelse. Trin 4: Etablering af en EA-kommunikationsplan, der kan fastholde alle interessenters fokus på EAprogrammet. Kommunikationsplanen skal sikre at alle kender til EA-programmets formål, metode og dokumentationsprincipper. Fase 2: Valg af dokumentationsværktøjer I fase 2 defineres de konkrete dokumenttyper, som EA-programmet skal arbejde med. Trin 1: Chefarkitekten vælger (efter dialog med EA-holdet og interessenterne) det overordnede rammeværktøj til EA-dokumentationen, samt værktøjets overordnede struktur, dvs hvilke komponenter, man vil anvende. Trin 2: Identificer de forretningsområder, som EA-programmet skal behandle. Evt horisontalt tværgående elementer, der kan behandles for sig selv, skal også identificeres (feks email). Trin 3: Identificer de enkelte komponenter, der skal dokumenteres. Dvs at dokumentationen for de fem niveau, de vertikalt tværgående emner (feks sikkerhed, standarder og medarbejdere) og de horisontalt tværgående emner, skal specificeres. Trin 4: Definer de enkelte artefakter som skal indgå i enterprise arkitekturen. Dette skal gøres i dialog med interessenterne, da det er disse, som vil skulle bruge dokumentationen. Trin 5: Vælg dokumentationsværktøj der kan understøtte de valgte artefakter. Trin 6: Etabler et on-line repository til EA-dokumentationen. Fase 3: Dokumentering af enterprise arkitekturen Når der er taget beslutninger om rammerne for enterprise arkitekturen og artefakterne, kan man gå i gang med at gennemføre det egentlige dokumentationsarbejde. Trin 1: Find frem til virksomhedens eksisterende dokumentation og indpas den i den valgte EA-dokumentationsstruktur. Trin 2: Skab de manglende artefakter, sådan at enterprise arkitekturen bliver komplet. Trin 3: Udvikling af et antal fremtidsscenarier, der afspejler mulige forbedringer og ny funktionalitet til de eksisterende systemer. Trin 4: Udvikling af et antal historier, der viser, hvad hver af de foreslåede fremtidsscenarier kunne munde ud i. Trin 5: Med udgangspunkt i scenarierne og historierne etableret under de foregående trin skabes dokumentation af de fremtidige komponenter. Dette fremtidige syn på enterprise arkitekturen skal dokumenteres med samme værktøjer som den aktuelle enterprise arkitektur, sådan at de nødvendige ændringer fremgår tydeligt. Trin 6: Skab en EA-ledelsesplan, der viser, hvordan man kan komme fra den aktuelle model til den fremtidige. Fase 4: Brug og vedligehold enterprise arkitekturen Når først fase 1-3 er gennemført, vil resten af EA-arbejdet foregå i fase 4. Trin 1: Enterprise arkitekturen kan efterfølgende bruges til planlægning og ledelse på - 3 -
mange niveauer. Det er derfor vigtigt, at al dokumentationen er nem at komme til for alle interessenter, via et repository. Trin 2: Sørg jævnligt for at enterprise arkitekturens aktuelle og fremtidige komponenter opdateres, sådan at de hele tiden afspejler virksomheden korrekt. Trin 3: Chefarkitekten og EA-holdet bør jævnligt evaluere EA-værktøjet og sikre opdateringen af de tilhørende dokumentationsværktøjer for at optimere virksomhedens værdi af enterprise arkitekturen. Trin 4: Chefarkitekten bør udsende årlige opdateringer over EA-ledelsesplanen til EAinteressenterne for at sikre, at alle løbende informeres om virksomhedens fremdrift. Sammenligning med Zachman Framework Metoder I modsætning til Zachman Framework, som jeg har skrevet om tidligere, er EA3 både et rammeværktøj og en metode. Zachman Framework er ikke nogen metode, men et rammeværktøj, der kan anvendes sammen med en hvilken som helst metode. Der er derfor ikke noget i vejen for feks at bruge Zachman Framework sammen med EA3s metode. Forretningsområder En anden forskel på de to metoder er brugen af forretningsområder. I EA3 er begrebet en integreret del af modellen, mens Zachman Framework skal bruges på et udvalgt interesseområde. Der er således ikke noget i vejen for at håndtere forretningsområder som udvalgte interesseområder og således opdele Zachman Framework i et antal forretningsområder på samme måde som EA3. Jeg ser dog en principiel forskel på de to tilgange til enterprise arkitektur. Ved at integrere forretningsområder som en central del af EA-modellen, skaber EA3 et fokus på at dele arkitekturen op i uafhængige segmenter. Dette virker imod den egentlige hensigt med en enterprise arkitektur, som er at danne et holistisk billede af virksomheden, der kan hjælpe til at optimere arbejdsgange og styrke genbrug. I mine øjne bør man først skabe denne type adskilte segmenter, hvis der er tungtvejende grunde til det. Niveauer EA3s fem niveauer minder lidt om Zachman Frameworks seks synsvinkler, idet det øverste niveau er det mest abstrakte og at de efterfølgende bliver mere og mere konkrete og teknologiske jo længere ned man bevæger sig. Men udover at udtrykke synsvinklerne via niveauerne definerer EA3 samtidig hvilke emner, der er er relevante på hvert niveau (feks at strategien hører til i toppen og infrastrukturen hører til i bunden). Princippet kan tydeligvis ikke gennemføres konsistent, da EA3 har måtte tilføje en undtagelse, netop til håndtering af de emner, der faktisk er interessante på alle niveauer (som sikkerhed, standarder og medarbejdere). Zachman Framework griber sagen an omvendt og foreslår at der på alle niveauer er noget interessant at sige om alle emner. Feks er den abstrakte oversigt, over hvilke lande en virksomhed opererer i, direkte forbundet med den valgte implementering af virksomhedens kommunikationsnetværk. Jeg mener derfor, at EA3 ikke får udnyttet en lang række forbindelser, der er mellem ledelsens synsvinkel og de implementerede systemer, og dermed går glip af en masse vigtig viden og kommunikation. - 4 -
Evaluering EA3 er, i mine øjne, en filtreret og forsimplet udgave af Zachman Framework, med særlig fokus på enterprise arkitektur. Zachman Framework er tænkt som et generelt rammeværktøj til dokumentation af hvad som helst (også en enterprise arkitektur). Derfor er Zachman Framework et mere komplet værktøj. Der er feks ikke noget i vejen for at bruge Zachman Framework i planlægningen af sin næste børnefødselsdag :-) EA3 fremstår som simplere end Zachman Framework, og den er nemmere at komme i gang med, da man får en færdig metode med i pakken. Jeg vil dog anbefale, at man sætter sig ind i begge dele, inden man tager sin beslutning om valg af EA-værktøj. Det er både muligt, på den ene side, at simplificere sin implementering af Zachman Framework, ved kun at inkludere de mest nødvendige artefakter, så dokumentationsarbejdet ikke bliver for stort, samt, på den anden side, at inkludere elementer fra Zachman Framework i en EA3-model, hvis det er den man vælger. Som tidligere nævnt kan EA3-komponenterne jo defineres frit af enterprise arkitekten. Afslutning Lærte du noget nyt? Er du enig i mine forklaringer og betragtninger? Jeg er meget interesseret i at høre din holdning til disse emner. Skriv til mig på Marc@SimplifySys.dk eller via kontaktsiden på min hjemmeside SimplifySys.dk. Her finder du også alle mine IT-relaterede artikler samt oplysninger om mine konsulentydelser og kursustilbud. Pas godt på hinanden - og husk ikke at gøre tingene mere indviklede end de er :-) - 5 -