Hvad er OIO EA

Nye behov + nuværende it = Fremtidens systemlandskab

OIO EA er en metode til at sammentænke nye forretningsmæssige behov med nuværende systemer og teknologier, samt med de muligheder ny teknologi tilbyder, og herudfra definere det fremtidige systemlandskab og dets implementering.

OIO EA præsenteres og vedligeholdes i dag af Digitaliseringsstyrelsen i Danmark på arkitekturguiden.digitaliser.dk.

Metoden består af 7 overordnede aktiviteter, som hver især består af 2-6 trin. Figur 1 viser OIO EA metoden (ea.oio.dk). OIO EA metoden er udarbejdet som en løbende, iterativ proces til at udvikle og vedligeholde en enterprise arkitektur. De enkelte trin i aktiviteterne eller al deres output behøves derfor ikke alle at blive udført – alt afhængigt af konteksten – ligesom der ikke er givet nogen specifik rækkefølge af deres udførelse.

OIO EA metoden

Figur 1: OIO EA metoden.

 

  1. Strategi – sikrer at enterprise arkitekturen forankres i forretningens behov.
    • De væsentligste tværgående udfordringer som organisationen står overfor skal identificeres. 
    • Der skal fra start opstilles rammer, der skal sikre at enterprise arkitekturen kan realises, at nøgleaktører involveres, og at der sikres et kontinuerligt forløb.
    • Formålet med enterprise arkitekturen og de nærmere rammer skal fastlægges og forankres.
    • Vision, mål, strategier og analyseres på organisationens forretningsmæssige side, for at identificere hvilke kritiske succesfaktorer, der har afgørende betydning for at målene og strategierne realiseres.
    • Der udvikles IT principper, herunder arkitektur principper og der analyseres hvilke konsekvenser disse har.
  2. Forretning – definerer den nuværende og fremtidige forretning i operationelle termer, så IT-brug kan optimeres til at understøtte forretningen.
    • De forskellige forretningsobjekter i en IT-infrastruktur skal identificeres.
    • Lokationer og organisationsstrukturer fastlægges og ansvarsområderne for de enkelte enheder afdækkes. Dette tjener til at identificere hvilke organisationer, lokationer og aktører der skal understøttes med IT, indenfor hvilke sammenhænge.
    • De services/tjenester organisationen leverer internt og eksternt skal beskrives. Disse skal ofte understøttes af IT – gerne på en mere hensigtsmæssig måde end i dag.
    • De forretningsprocesser organisationen opererer med skal afdækkes og de mest kritiske identificeres; der hvor IT-indsatsen skal fokuseres og om muligt forbedres.
    • En use case skal udarbejdes til at forankre det videre arkitektur-arbejde hos brugerne.
    • Use casen skal konkretiseres i mere operationelle workflows, hvor det mere detaljeret vises hvordan de enkelte aktører i samarbejde løser en række opgaver i trin.
  3. Teknik – sikrer at den nuværende teknik-arkitektur dokumenteres, og at den fremtidige (3-5 år) arkitektur defineres.
    • Den nuværende og den fremtidige informationsarkitektur beskrives.
    • Der defineres hvilke applikationer og integrationer der nu understøtter, og fremover skal understøtte organisations arbejdsgange. Et fundament skabes herved for at planlægge nødvendige udfasninger af eksisterende applikationer og implementering /integration af de nye.
    • Både de nuværende og fremtidige servicearkitekturer beskrives, med det formål at øge genbrugelighed; del ved at konsolidere fælles services der, og dels ved at lade applikationer publicere deres services til omverdenen.
    • Teknologiarkitekturens nuværende og fremtidige trin beskrives for at kunne fastlægge organisationens plan for brug af strategiske teknologier, på en måde der effektivt koordinerer udviklings-/vedligeholds-ressourcer og konsoliderer nøgleteknologier.
  4. Gap analyse – sikrer at forskellen mellem den nuværende og den ønskede IT arkitektur analyseres, således at et solidt grundlag for en migrationsplan tilvejebringes.
    • De restriktioner af teknisk og forretningsmæssigt art, der forefindes, skal identificeres, for at kunne tage højde for dem i udarbejdelse af en migreringsstrategi og –plan.
    • De projekter der måske ikke er strategiske og en del af enterprise arkitekturen, men som er taktiske og på kort tid og uden en stor indsats kan give en gevinst i form af effektivitet, besparelser og kvalitetet, skal identificeres.
    • Formålet med Gap analysen er at analysere forskellene på den nuværende arkitektur og den fremtidige arkitektur, for derved at påbegynde planlægningen af denne migrering.
  5. Forandring – sikrer at den fremtidige Enterprise Arkitektur realiseres.
    • Formålet med at udarbejde en overordnet ramme for migreringen (migreringsstrategi), hvor de forretningsmæssige ønsker til migreringen fastslås. Ligeledes afdækkes de rammer som organisatoriske hensyn sætter.
    • En migreringsplan er en overordnet projektplan for de kommende års migreringsprojekter. Hvert enkelt grovestimeres, en deltaljeret projektplan udarbejdes senere.
    • En konsekvensanalyse laves for at afdække konsekvensen af de foreslåede projekter – hvad betyder de for kunderne og brugerne. Analysen bør indeholde en indsatsplan for de områder hvor konsekvenserne kan være store.
  1. Tekniske og forretningsmæssige trends – berører de trends, som organisationen kan (men ikke behøver) at tage højde for.
    • Der bør udarbejdes en oversigt over de forretningsmæssige trends, som kan tænkes at skulle arbejdes ind i IT-arkitekturen. En forretningsmæssig trend er en tendens som man kan overveje i sin fremtidige tilgang til forretningen.
    • Formålet med dette er at udarbejde en oversigt over de tekniske trends som er oppe i tiden, og som kan overvejes taget ind i enterprise arkitekturen. En teknisk trend kan være at lave arkitekturen service-orienteret (SOA).
  2. Principper og styring – berører de styringsmekanismer og rammer der er, omkring lovmæssige og kontraktuelle forhold, og omkring budget- og driftsstyring.
    • At udarbejde og vedligeholde en sammenhængende driftssituation. Organisationers forretningsprocesser er i stor udstrækning understøttet af IT, og løbende ændringer i forretningsbehov stiller også krav til IT-driften om hurtig omstilling og effektiv drift.
    • Budget og ressourcestyring: at styre porteføljen af foreslåede projekter der har EA relevans, og herunder prioritere og allokeres ressourcer.
    • EA governance udarbejdes for at sikre at arkitekturen publiceres/kommunikeres, overholdes, implementeres, overvåges og opdateres.
    • Der er visse lovmæssige bindinger, der skal overholdes: dette gøres ved at udarbejde en oversigt over gældende love (og EU-direktiver), der er relevante for en given organisations IT-brug.
    • Kontrakt- og aftaleforhold: Der skal udarbejdes en oversigt over de indgåede aftaler, der er relevante at tage i betragtning ved udviklingen og implementering af en enterprise arkitekturs it-elementer. Med sådan en oversigt kan man bedre tilrettelægge planen for implementeringen af enterprise arkitekturen – både drage nytte af eksisterende aftaler, og sikre at man ikke bryder indgående aftaler.