Nem EA crash course

Her får du et crash-course i OIO EA metoden.

OIO metoderammen svarer til andre nationale og internationale metoderammer for processer og dokumentation af enterprise arkitektur. Du kan læse om forholdet mellem OIO EA og andre metoderammer her

Klik på links for at komme til en detaljeret beskrivelse. Du kan også klikke på billedet og komme direkte til hovedsektionen om OIO EA, hvor du også finder en vejledende introduktion.

A. Strategi

Strategiaktivitetens mål er at sikre at enterprise arkitekturen og løsningsprojekter er forankret i forretningens behov.

  • Vision, mål og strategier sammenfatter organisationens forretningsmæssige vision, mål og strategier, og udleder derfra kritiske succesfaktorer. Også analyser af interessentforhold og af organisationens stærke og svage sider, muligheder og trusler, vil ofte indgå her.
  • Udfordringer afdækker hvilke udfordringer – problemer og muligheder – OIO EA skal adressere.
  • Principper definerer de it-principper som organisationen bekender sig til, og som sætter retningslinierne for teknologivalg senere.
  • Måling fastlægger og analyserer kritiske succesfaktorer og målepunkter, der har afgørende betydning for at mål og strategier (herunder målarkitekturen) realiseres.
  • Programmer og projekter opstiller programmers og projekters grundlag og rammer. 
  • Metode tillemper den generelle OIO EA metode (og andre metoder der anvendes) til organisationens behov i et konkret enterprise arkitektur-forløb.

B. Forretnings-aktiviteten

Forretnings-aktivitetens mål er at få forretningen – og her primært den fremtidige – defineret i operationelle termer, som et skridt på vejen mod at sikre at it-brugen optimeres til at understøtte konkrete opgaver og arbejdsgange.

De enkelte delaktiviteter kan udføres i forskellig rækkefølge, herunder også i parallel:

  • Forretningsobjekter identificerer de begreber eller ”forretningsmæssige objekter” der anvendes af forretningssiden i organisationen – såsom: ”borger”, ”henvendelse”, ”areal”, ”bygning” etc.
  • Organisation beskriver de organisationsenheder og/eller lokationstyper der har behov for strategisk it understøttelse for bedre at kunne udføre deres arbejde og dermed realisere forretningens mål.
  • Forretningsservices beskriver de forretningsmæssige services som organisationen tilbyder sin omverden – borgere, firmaer, kunder, etc.
  • Processer beskriver de processer man arbejder efter i organisationen. Der vil være nogle hovedprocesser der resulterer i levering af organisationens forretningsservices, og nogle støtteprocesser for disse. Kan også på et dybere detaljeringsniveau konkretisere use cases ved at beskrive mere operationelt hvordan de enkelte opgaver løses i arbejdsgange (workflows).
  • Forretningsregler konkretiserer use casene til mere operationelle workflows – hvor det mere detaljeret vises hvordan de enkelte aktører i samarbejde løser en række opgaver i trin
  • Use cases beskriver hvilke opgaver hvilke aktører løser hvordan. Fokus er på hvad der udføres, ikke hvordan.

C. Teknik

Teknik-aktivitetens mål er at sikre at den nuværende teknik-arkitektur (baseline eller AS IS) dokumenteres, og at den fremtidige arkitektur (målarkitektur eller TO BE) bliver defineret (3-5 år ud i fremtiden). Både den nuværende og den fremtidige arkitektur defineres indenfor fire områder:

De enkelte delaktiviteter er:
  • Informationsarkitektur der dokumenterer den nuværende, og designer den fremtidige informationsarkitektur. Begge omfatter logiske datamodeller og fysiske database strukturer og data distributionsskemaer.
  • Applikationsarkitektur der dokumenterer den nuværende, og designer den fremtidige applikationsarkitektur. Fokus er på at få beskrevet applikations- og integrationslandskabet, herunder funktionalitet af de enkelte applikationer, og på hvilke integrationer der er/skal foretages. Denne aktivitet beskriver også hvordan applikationerne bruges, og hvilke informationer de genererer og bruger – men derimod ikke hvordan applikationerne konstrueres.
  • Servicearkitektur der komplementerer Applikationsarkitektur, idet den kigger ”ind i maven” på de enkelte applikationer, med det mål at søge at gøre dem komponentopdelte, og at identificere services der med fordel kan gøres fælles for flere applikationer, og implementeres som web services.
  • Teknologiarkitektur dokumenterer den nuværende, og designer den fremtidige teknologiarkitektur der underliggende understøtter applikationer og data.  Dette omfatter både selve infrastrukturen (såsom klienter, servere og netværk) og management af denne (systems management, sikkerhed).

D. Gap-analyse

Gap analyse-aktivitetens mål er at sikre at forskellen mellem den nuværende og den ønskede it arkitektur analyseres, således at et solidt grundlag for en migrationsplan tilvejebringes.

De enkelte delaktiviteter er:

  • Restriktioner giver en oversigt over restriktioner, der skal tages højde for i en migrationsplan.
  • Muligheder afdækker muligheder (projektforslag) der gavner virksomheden forretningsmæssigt, teknisk eller økonomisk.
  • Gap analyse analyserer forskellene mellem den nuværende og den fremtidige arkitektur, som et grundlag for at lave en migrationsplan.

E. Forandring

Forandrings-aktivitetens mål er at sikre, at de forretningsmæssige mål og enterprise arkitekturen realiseres.

De enkelte delaktiviteter er:

  • Migreringsstrategi tilvejebringer overordnede retningslinier for hvordan en migrering til det ønskede fremtidige it-landskab kan realiseres.
  • Migreringsplan realiserer strategien til en konkret plan, der identificerer og i en vis detaljeringsgrad beskriver større it projekter de næste 3-5 år.
  • Konsekvensanalyse identificerer de konsekvenser de foreslåede migreringsprojekter kan have, ikke mindst hvordan de kan påvirke medarbejdere og brugere, og foreslå hvordan man kan mindske negative påvirkninger.

X: Tekniske og forretningsmæssige trends

Trends berører de muligheder som organisationen kan (men ikke behøver) at tage højde for.

De enkelte delaktiviteter er:

  • Forrentningsmæssige trends som giver input i form af et overblik over hvilke forretningsmæssige tendenser, der bør overvejes tænkt ind i forretningen og dermed i enterprise arkitekturen.
  • Tekniske trends giver input i form af et overblik over hvilke tekniske tendenser, der bør overvejes tænkt ind i ligeledes i forretningen, men naturligvis også i teknikunderstøttelsen, og dermed i enterprise arkitekturen.

Y: Styring

Styring indeholder aktiviteter, der berører alle de styringsmekanismer og givne rammer, der er omkring projekter og løsninger og sikrer styring på tværs af de øvrige akviteter.

De enkelte delaktiviteter er:

  • Sikkerhed skal sørge for at der er fokus på sikkerhed fra start til slut med udgangspunkt i en overordnet strategi og en konkret risikovurdering.
  • Budget og ressourcer beskæftiger sig med styring af ressourcer og budgetter der – blandt andet – skal sikre at enterprise arkitekturen implementeres.
  • It-arkitekturstyring adresserer allerede fra starten af et (EA) projekt, hvordan arkitekturen kan realiseres i den givne organisation, og påbegynder mobiliseringen af en (EA) governance struktur. Denne aktivitet er central i EA-sammenhæng, idet den etablerer en struktur og processer, der kan sikre at enterprise arkitekturen holdes levende og løbende opdateres, kommunikeres og anvendes.
  • Lovmæssige bindinger giver et overblik over de bindinger der er defineres af love og regler nationalt, i EU eller internationalt og som skal tænkes ind i enterprise arkitekturen.
  • Kontrakter og aftaler giver et overblik over de kontraktmæssige forpligtigelser der kan påvirke planen for realiseringen af enterprise arkitekturen.
  • Drift vedrører den løbende drift af it-systemerne. Dokumentationen herfra omfatter driftsmanualer, procedurer for at håndtere it-brugerhenvendelser og lignende.
  • Kravhåndtering har til formål at styre krav i relation til projekter og udbud, og gøre det i et EA perspektiv og i en livscyklus. Det skal sikre at organisationen dokumenterer, kontrollerer og opfylder behovene og forventningerne hos interne eller eksterne interessenter.

 

Permanent URL til denne artikel: http://arkitekturguiden.digitaliser.dk/node/209