Den røde tråd

OIO EA metoden er en ramme, der altid vil skulle tilpasses den enkelte organisations behov, og under brug af det allerede eksisterende – i forretningen og i informations-teknologianvendelsen. OIO EA’s vigtigste mål er at sikre at teknologi-beslutninger og teknologi-projekter er solidt forankrede i forretningens mål og strategier, og hjælper til at gennemføre disse. OIO EA skal kort sagt kunne bruges til at prioritere og retfærdiggøre alle større teknologiinvesteringer og aktiviteter som en organisation foretager.

Den røde tråd i OIO EA metoden er altså at sikre broen mellem forretning og informations-teknologi. Nedenfor er anført et eksempel på hvordan dette kan gribes an i en konkret situation.

Eksempel: OIO EA brugt i infrastrukturkonsolidering

Scenarium: To eller flere organisationer skal slås sammen, og forskellige infrastrukturer konsolideres. I dette scenarium er fokus på at sikre at den basale infrastruktur hurtigt etableres, så den kan levere de mest essentielle services og samtidig kunne understøtte fremtidige applikationer og services, uden disse dog endnu er defineret helt præcist.

OIO EA kan i dette scenarium med fordel anvendes som beskrevet nedenfor (hvor røde pile angiver at der defineres fremtidige arkitekturer for det område hvor pilen ender, blå at der dokumenteres nuværende arkitekturer for hvor pilen ender, og stiplede linier at trinet kun i et vist omfang udføres):

OIO EA brugt i infrastrukturkonsolidering

 

 

 

Man vil starte med i A3 at præcisere OIO EA metodetillempningen, sådan som her skitseret, men med mere detalje i hvilke output de enkelte trin leverer. Dette inkluderes i et projekt-charter i A4, hvor projektaktiviteter, tidsfrister og ansvarlige for de enkelte trin fastlægges.

Herefter starter det egentlige projekt, og man bemærker at der tilsigtes – og kan opnås – en stor grad af parallelitet, for at fremskynde infrastrukturkonsolideringen:

På tekniksiden vil man straks gå i gang med at få dokumenteret den nuværende arkitektur (blå pile) – og selv her kan man dokumentere den nuværende applikations-, service-, og teknologi-arkitektur i parallel. Teknologiarkitekturen (C4) vil man give størst fokus, men det er nødvendigt at have et vist overblik over hvilke teknologi-krav de nuværende applikationer (C2) og services (C3) stiller til den underliggende infrastruktur, for at kunne imødekomme disse i den kommende.

På strategi/forretningssiden vil man i et vist omfang sikre at forretningens mål og strategier dokumenteres så de er i mente, og ligeledes i et vist omfang få beskrevet hvilke forretningsservices der fremover skal kunne leveres (B3). Disse kan med en vis fordel uddybes med udvalgte Use cases (B5) og workflows (B6), om end disse to trin ikke bør fylde meget. Vigtigst i forretningsaktiviteten er at få defineret hvilke fremtidige lokationer/organisationsstrukturer (B2) den kommende organisation vil få, og som den kommende infrastruktur derfor skal kunne understøtte.

    Når den nuværende teknik-arkitektur og den fremtidige forretningsarkitektur begge er dokumenterede, går arbejdet med at designe den fremtidige infrastruktur i gang:

    Man vil i et vist omfang skitsere hvilke fremtidige applikationer (C2) og fremtidige services (C3) der skal kunne understøttes af en infrastruktur. Dette ikke for at definere disse i stor detalje (funktionalitet, præcise valg af softwarepakker, dataudvekslingsformater, osv.), men kun for at sikre at man kender fremtidige applikationers og services forventninger til den fremtidige infrastruktur – udviklingsmiljøer, netværksstruktur, osv.

    Herefter defineres den fremtidige teknologiarkitektur (C4) – netværk, operativsystemer på klienter og servere, infrastrukturtjenester såsom mail, intra/extranet og portalteknologier, databaseteknologier, udviklingsmiljøer, osv. Denne defineres ret grundigt, med præcise specifikationer af infrastruktur-topologier og valg af teknologier og teknologi-standarder for de enkelte noder (byggeblokke) i topologierne. Det vil også være meget relevant at specificere system management- og sikkerhedsaspekter af infrastrukturen.

      Projektet fortsætter nu med en gap analyse (D3) der holder den nuværende teknologiarkitektur op imod den fremtidige, og på baggrund af dette definerer en migreringsstrategi (E1) og efterfølgende en detaljeret migreringsplan (E2), der beskriver migreringsprojekter og deres sammenhænge, og estimerer ressourceforbrug. Denne kan med fordel komplementeres af en konsekvensanalyse (E3), der blandt andet identificerer organisatoriske aspekter ved migreringsplanen der skal tages højde for, også selv om de ikke er en del af implementeringen af teknikken.

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