OIO Enterprise Arkitektur

Transkript

1 OIO Enterprise Arkitektur OIO EA scenarier Version 1.0 Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. EA governance strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Principper og styring Y2. Budget- og ressourcestyring Y1. Driftssituation Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Ministeriet for Videnskab, Teknologi og Udvikling Januar 2007

2 Om dette dokument Dette dokument giver eksempler på OIO EA metodens anvendelse i konkrete situationer scenarier. Dokumentet er beregnet til enterprise og it-arkitekter, projektledere og teknikere, der ønsker en vejledning a konkret at bruge OIO EE. Scenariesamlingen er ikke komplet nogle af scenarierne er blot foreslået, men endnu ikke gennemarbejdet.. OIO Enterprise Arkitektur dokumentsamlingen omfatter (december 2006) følgende dokumenter: Introduktion til OIO EA metoden (OIO EA) De enkelte trin i OIO Enterprise Arkitektur metoden (OIO EA) OIO scenarier OIO EA relateret til andre EA metoder og rammeværk OIO EA FAQ Alle dokumenterne kan findes og downloades på ea.oio.dk/download. IT- og Telestyrelsen har søgt at udarbejde og præsentere en effektiv, pragmatisk enterprise arkitektur metode og ramme, baseret på både velafprøvet teori og praktisk erfaring. IT- og Telestyrelsen kan dog ikke påtage sig ansvar for resultatet af brug af OIO EA metoden og OIO Arkitekturguiden, hverken i eget brug eller brugt som fundament for ydelser udbudt til andre. Et vellykket udbytte af metoden/rammen kræver de rette kompetencer og ressourcer, projektledelse, osv. forhold der er udenfor metoden/rammen at sikre. Indholdsfortegnelse 1 Introduktion Dimensioner i anvendelsen af OIO EA Valg af trin For valgte trin: valg af dimensioner Scenarium: Infrastrukturkonsolidering Situation Mål og fokus Rolleovervejelser Flow og trintilpasninger af OIO EA metoden Scenarium: Proces-orienteret brug af OIO EA Situation Mål og fokus Rolleovervejelser Flow og trintilpasninger af OIO EA metoden Scenarium: Informations-orienteret brug af OIO EA i en sektor Situation Mål og fokus Rolleovervejelser Flow og trin-tilpasninger af OIO EA metoden Scenarium: Webmasters brug af OIO EA Situation OIO EA scenarier v1.doc Side 2 af 22 Januar 2007

3 6.2 Mål og fokus Rolleovervejelser Flow og trintilpasninger af OIO EA metoden OIO EA scenarier v1.doc Side 3 af 22 Januar 2007

4 1 Introduktion Ministeriet for Videnskab, Teknologi og Udvikling udgav i oktober 2004 Arkitektur for digital forvaltning Håndbog om begreber, rammer og processer, også blot kaldet Håndbogen. Dette dokument beskrev hvordan den offentlige forvaltning mødes af nye krav og ønsker, der kræver en systematisk planlægning af brugen af it for at kunne opfyldes. Denne planlægning skal 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 hvordan dette realiseres. En sådan ramme for dette kaldes en enterprise arkitektur, ofte forkortet EA. Det videre arbejde har ført til udviklingen af en egentlig metode for udvikling af enterprise arkitektur, kaldet OIO EA metoden. Denne er angivet nedenfor: Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. EA governance strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Figur 1: Håndbogens EA metode udvidet til OIO EA metoden. De store områder (de fem midterste, blåviolette, samt det øverste lyseblå og nederste bordeuax) kaldes aktiviteter. En aktivitet indeholder 3-6 trin. OIO EA metoden beskriver systematisk hvert trin formål med trinet, aktører i trinet, input til trinet og output fra dette, metodeovervejelser, gode råd, eksempler, referencer og mere. OIO EA arkitekturguiden kan bruges til forskellige formål, herunder: Gennemførelse af et it-projekt. Gennemførelse af et it-udbud. Konsolidering af arbejdsgange i forbindelse med strukturreformen. Konsolidering af informationsarkitekturen på enterprise niveau. OIO EA scenarier v1.doc Side 4 af 22 Januar 2007

5 Udarbejdelse af delvis enterprise arkitektur, fx konsolidering af infrastruktur. Udarbejdelse af en fuld enterprise arkitektur for en myndighed. Udarbejdelse af arkitektur for datainfrastruktur i en sektor, i multisektor eller fællesoffentligt. Udarbejdelse af arkitektur for fællesoffentlig infrastruktur. Det er vigtigt at bemærke at OIO EA metoden er en ramme, der altid vil skulle tilpasses den enkelte organisations behov, og under brug af det allerede eksisterende. OIO EA s vigtigste mål er at sikre at teknologibeslutninger 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 it. I kapitel 3 og frem gives eksempler på hvordan dette kan gøres, i udvalgte scenarier. OIO EA scenarier v1.doc Side 5 af 22 Januar 2007

6 2 Dimensioner i anvendelsen af OIO EA 2.1 Valg af trin OIO EA metoden er en rammemetode, der altid vil skulle tilpasses den enkelte organisations behov, og under brug af de allerede eksisterende OIO EA-lignende dokumenter. Formålet er altid at sikre at man med mindst muligt brug af ressourcer når de fleste af de svar der søges, og dermed de mål der ligger bag indsatsen. Man kan naturligvis godt bruge halve eller hele år på at gennemløbe alle trin i OIO EA, og dermed få 95% af svarene. Ofte er fokus imidlertid på et meget mindre område end en hel enterprise arkitektur, for eksempel orienteret mod at optimere procesunderstøttelsen via bedre applikationer. I mange tilfælde er det derfor langt mere effektivt at gennemarbejde de 20% af trinene der giver de 80% af svarene. Kunsten er naturligvis at finde disse 20% af trinene. Denne tilpasning foregår i OIO EA metodens trin A3. EA metodegrundlag, i samspil med trin A4. EA projekt charter. Vi giver i de følgende kapitler eksempler på hvordan OIO EA metoden kan bruges i en række forskellige scenarier. 2.2 For valgte trin: valg af dimensioner Når man har valgt OIO EA trin, skal man også afgøre omfanget af hvordan trinene gennemløbes. Dette gøres ud fra tre dimensioner, illustreret nedenfor: Fagspecifikt Generelt Dele af organisationen Hele organisationen Forretningsorienteret Teknologiorienteret De tre scope -dimensioner til overvejelse er: Figur 2: Dimensioner i brug af OIO EA metoden. Orientering: Er enterprise arkitektur-projektet forretningsorienteret, teknologiorienteret, eller begge dele? Da enterprise arkitetur i høj grad stiler mod at bygge bro mellem de to, vil de fleste EA projekter rumme elementer af begge dele. Men fokus kan sagtens være mest på den ene, eksempelvis kan forretningssiden være helt afklarede og have veldokumenterede mål, strategier og fremtidige arbejdsprocesser, som EA så skal rette teknologisiden ind til. Organisation: Er enterprise arkitektur-projektet rettet mod hele organisationen, eller liniespecifikt for dele af organisationen, for eksempel mod en enkelt styrelse/et enkelt direktorat, eller måske ligefrem rettet mod samarbejdende enheder på tværs af flere organisationer? Fagbredde: Er enterprise arkitektur-projektet fokuseret på generelt at etablere en ny enterprise arkitektur, der omfatter alle fagområder, eller er fokus rettet fagspecifikt på for eksempel kun de brugervendte funktioner/systemer eller kun mod de administrative systemer? OIO EA scenarier v1.doc Side 6 af 22 Januar 2007

7 Det er vigtigt at bemærke at enterprise arkitektur ikke betyder at man altid gør alt for alle. OIO EA tilbyder en samling metoder og teknikker der kan bruges også i snævrere sammenhænge, men stadig have det for øje at sikre en snæver kobling mellem forretningsbehov og it understøttelse. De følgende kapitler illustrerer hvilke overvejelser man kan gøre sig i forskellige scenarier. OIO EA scenarier v1.doc Side 7 af 22 Januar 2007

8 3 Scenarium: Infrastrukturkonsolidering 3.1 Situation 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 nødvendigvis endnu er defineret helt præcist. Der vil typisk være tale om: Nye/modificerede services skal konsolideres og leveres i den sammenlagte organisation. Ny/modificeret infrastruktur skal understøtte de mere basale services, såsom fælles , fælles intranet og extranet portal, osv. Nye/modificerede fagsystemer. Man bruger muligvis en del fælles fagsystemer, men de er højst sandsynligt konfigureret forskelligt og der er sikkert også fagsystemer der er ret forskellige. 3.2 Mål og fokus I et relativt presset forløb som det er at få et par organisatoriske enheder til at fungere som én, er det vigtigt at sætte sig mål der er realistiske. Det vil sige: Relativt hurtigt at få etableret de mest grundlæggende arbejdsgange for den samlede organisation. Det medfører i dette scenarium at afdækningen af opgaver der bestemt er relevante, men måske ikke forretningskritiske på den korte bane, nedprioriteres lidt i første gennemløb af en OIO EA. Dette betyder at informationsarkitekturen og procesanalysen prioriteres lavere end det at få etableret en sammenhængende infrastruktur. At få afdækket de væsentligste arbejdsgange hvor forretningssiden kan forvente lidt større ændringer. Ikke at man nødvendigvis løser alt i denne iteration af OIO EA, men at man i al fald sikrer, at den infrastruktur der designes, passer til de fremtidige krav. At sikre at den basale infrastruktur hurtigst muligt bliver integreret, således at man har en fælles rygrad af almene systemer , intranet med kalender, adressebog osv. Den fælles infrastruktur er essentiel, uanset hvilke fagsystemer der senere vælges. Derefter at sikre et overblik over hvilke fagsystemer der skal leve videre i den sammenlagte organisation, og i hvilken rækkefølge der skal migreres, udfases, osv. I de ovenfor beskrevne dimensioner kan man afbilde fokus således: Orientering Organisation Fagbredde Teknologiorienteret Forretningsorienteret Hele organisationen Dele af organisationen Generelt Fagspecifikt Om orientering: Enterprise arkitektur-opgaven vil fokusere på teknologi-delen. Men der vil på det operationelle plan være behov for at præcisere nogle af de centrale forretnings-arbejdsgange. Om organisation: fokus er på hele organisationen først og fremmest; de store linier. Om fagbredde: igen må det generelle have første prioritet, men der er dog god grund til at scanne de nye krav til fagsystemer, for at sikre at disse kan mødes senere, om end den initielle EA aktivitet vil fokusere mest på de generelle krav. 3.3 Rolleovervejelser En sammenlægning vil være en stor forandring for mange af de ansatte i organisationerne. Ikke at der nødvendigvis rent faktisk sker en stor omvæltning af det daglige arbejde, men der vil alligevel ske forandringer for mange, af et eller flere af følgende: (1) fysisk arbejdslokation, (2) nye kollegaer, (3) nyt arbejdsansvar, og (4) nye systemer til at løse opgaverne med. En enterprise arkitektur skal primært understøtte punkt (4), men det er OIO EA scenarier v1.doc Side 8 af 22 Januar 2007

9 vigtigt at den gruppe af personer der forestår udarbejdelsen af den nye arkitektur er meget bevidste om de øvrige forhold, der kan påvirke arbejdet. De roller der er vigtige at få besat er: En forandringsarkitekt, der kan sikre at hele forløbet af det at udarbejde en ny enterprise arkitektur afmystificeres og indarbejdes som en naturlig del af at have nye arbejdsopgaver. En forretningsarkitekt, der kan sammenfatte de ønsker til de tjenester som den nye organisation skal udbyde til dens borgere og virksomheder. En teknologiarkitekt, der kan skabe et overblik over den it-infrastruktur der forefindes, og i samarbejde med de enkelte organisationers teknologi-kyndige udarbejde en plan for den konsoliderede itinfrastruktur. En applikationsarkitekt, der kan skabe overblikket over hvordan de fremtidige fagsystemlandskab bør se ud. Og ikke mindst: en enterprise arkitekt, der kan holde overblikket over samtlige de aktiviteter der her foreslås, og sikre en kontinuitet og at der etableres den bro mellem forretningssiden og teknologien der kan gøre den nye organisation driftssikker fra start. Alle roller kan besættes både internt, men også med ekstern hjælp. Det er dog anbefalelsesværdigt at sikre at der forbliver en intern, samlende kompetence i den nye organisation. 3.4 Flow og trintilpasninger af OIO EA metoden 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) Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. EA governance strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Nuværende arkitektur Fremtidige arkitektur Følgende bemærkes: Figur 3: OIO EA brugt i infrastrukturkonsolidering. Projektets charter og tilpasningen af arkitekturmetoden udvikles i parallel. Man starter med de retningslinier og ønsker som forretningssiden udtrykker via dens vision, mål og strategier (A5), og som er videreudviklet til nogle højniveau it-principper (A6). Man kan sagtens og med fordel arbejde med forretning i parallel med at man dokumenterer den nuværende it-arkitektur (en del af de fire trin C1-C4). Dokumentationen af den nuværende arkitektur er ikke teknisk set svært, men kan være tidskrævende, så det er en fordel at parallelisere det med arbejdet på OIO EA scenarier v1.doc Side 9 af 22 Januar 2007

10 forretningssiden, så der er et teknisk grundlag for at designe den fremtidige arkitektur, når forretningens operationelle behov er veldokumenterede. Udviklingen af B3 Forretningsservices til C3. Servicearkitektur er tæt forbundet med de øvrige leverancer i både Forretnings- og Tekniktrinene. De fremtidige forretningsservices skal afstemmes med de mere detaljerede Use Cases og workflows hvori de indgår, og fremtidige teknologiservices i C3 afstemmes med den teknologiinfrastruktur og det fremtidige applikationslandskab hvori de skal realiseres. EA projektopstarten foregår således: A3. Metodegrundlag: 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. A4. Projekt charter: Her dokumenteres helt konkret hvem der deltager i hvilke trin. Arbejdsopgaver og arbejdsgange aftales, og der sikres opbakning omkring enterprise arkitektur projektet. Endvidere fastlægges projektaktiviteter, tidsfrister og ansvarlige for de enkelte trin. Det er vigtigt at konkrete personer udpeges både de mere udførende kræfter, men også de personer i den nye organisation der skal stå som garanter for at arkitekturen realiseres. 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 fremtidige arkitektur. 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, etc.), 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 infrastrukturtopologier 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. Uddybende bemærkninger til de enkelte trin: OIO EA scenarier v1.doc Side 10 af 22 Januar 2007

11 A5. Vision, mål og strategier: Dette trin udføres ret hurtigt, og har til formål at opsummere og konsolidere de mål der er med organisationssammenlægningen, og at opsamle de lokale strategier som den forenede organisation har udarbejdet. Dette trin kræver altså en involvering af de nye ledere ikke for at ændre deres mål, men for at sikre at de er velforståede, og at de støtter den opgave som EA vil udføre, nemlig at indføre en it infrastruktur og de fagsystemer man fremover skal betjene sig af. A6. It-principper: Dette trin vil også skulle udføres ret hurtigt, og sigte mod at identificere og dokumentere de it-principper der er fælles for den sammenlagte organisation, således at disse principper kan tjene som beslutningsgrundlag. B2. Lokalitioner/organisation: Det er naturligvis relevant at præcisere hvilke fremtidige lokationer og organisationsstrukturer den kommende organisation vil få. Hvis der er tale om en organisation med lokal udbredelse, for eksempel en kommune, vil man med fordel kunne kombinere beskrivelsen af lokationer og organisatoriske enheder (modsat hvis det var en global organisation, med mange fysiske lokaliteter). B3. Forretningsservices: Man vil tage udgangspunkt i hvilke forretningsservices den fremtidige organisation forventes at leveres. Opgaven her vil bestå i at få et overblik over hvilke services de enkelte organisationer i dag leverer, og hvilke man fremover ønsker at tilbyde. Aktiviteten bør resultere i følgende leverancer: Et overblik over de ønskede forretningsservices En mapning af disse services imod de organisatoriske enheder/lokationer der skal levere tjenesterne. Denne vil senere tjene til at designe en god systemtopologi (i C4). B5. Use Cases: Det vil give god mening at kombinere B2 og B3 og bryde beskrivelsen af disse ned til mere detaljerede Use Cases og workflowbeskrivelser. Man bør lave et generelt overblik over arbejdsopgaver, men dette kan gøres relativt hurtigt, og man bør fokusere på de områder hvor der er mest tvivl blandt organisationens ansatte over hvilke nye arbejdsopgaver der forventes løst. Her giver det god mening at have workshops med medarbejderne, hvor man i detaljer får deres input til hvilke opgaver der skal løses, og hvordan. B6. Workflow: Nogle Use Cases vil med fordel skulle detaljeres i egentlige workflow beskrivelser. Man bør ikke gøre det for alle, men fokusere på hvor Use Casene afslører en uenighed mellem forskellige organisatoriske enheder i den kommende organisation, og hvor man bliver nødt til at afstemme aftaler om fremtidige arbejdsformer gennem workshops med de involverede brugere. C2. Applikationsarkitektur: Man vil her beskrive: En oversigt over applikationer og integrationer, som de forefindes nu. Den fremtidige applikationsarkitektur: her vil forskellige fagsystemer skulle slås sammen, så der kun er ét for hvert område, på tværs af organisationen. C3. Servicearkitetur: Den fremtidige servicearkitektur vil blive udarbejdet i samspil med leverancerne i C2 og C4. Trinet leder til en kortlægning af hvor de forretningsservices, som B3 identificerede, bedst realiseres både under hvilken infrastruktur, og hvilke applikationer der har brug for hvilke services. En mapning af hvilke services (B3) der leveres fra hvilke applikationer i dag. C4. Teknologiarkitektur: I teknik-aktiviteten kommer man til at lave en ret komplet arkitektur, der beskriver: Teknologi-oversigt: oversigt over brug af teknologier, teknologikonfigurering af platforme (ABBs arkitektur byggeblokke ), og en oversigt over systemtopologien i de indgående organisationer. Den nuværende og fremtidige teknologiarkitektur: en infrastrukturkonsolidering, hvor for eksempel forskellige mailsystemer, netværksteknologier og arbejdsstationskonfigurationer konsolideres. Som et led i Teknikaktiviteten kommer man også til at forholde sig til hvordan man bedst komponentopdeler og service-orienterer den fremtidige arkitektur. Muligvis vil man også skulle tage stilling til en informationsarkitektur, herunder brug af OIOXML og andre offentlige standarder. OIO EA scenarier v1.doc Side 11 af 22 Januar 2007

12 D3. : Her vil man lave en oversigt over de projekter der skal til for at lede den nuværende arkitektur frem til den fremtidige, som defineret i C2, C3 og C4. Herefter vil man gruppere dem efter (1) hvor vigtige de er (jfr. hvor meget de hver især realiserer de services og den infrastruktur der ønskes, og (2) efter i hvilken rækkefølge de i praksis kan realiseres. Man kan for eksempel ikke påbegynde nye applikations/service-projekter før den underliggende infrastruktur er på plads. E1. Migreringsstrategi: I arbejdet med en migreringsstrategi er det vigtigt at erkende de organisatoriske forhold der gør sig gældende, og det er vigtigt at sikre involvering fra de personer der skal sikre enterprise arkitekturens videre gennemførelse. I dette scenarium er det vigtigt at få udstukket de principper for migrering som beslutningstagerne i den nye organisation vil anse for realistiske, og aktivt understøtte. E2. Migreringsplan: Da sammenlægningen af organisationerne helst skal være tilendebragt i løbet af så kort tid som muligt, vil man med fordel udarbejde en relativt detaljeret migreringsplan, der beskriver migreringsprojekter og deres sammenhænge, og grovestimerer ressourceforbrug. Planen laves med input af de fleste af de foregående leverancer applikations/service/teknologi-arkitekturen, gap analysen og migreringsstrategien ikke mindst. OIO EA scenarier v1.doc Side 12 af 22 Januar 2007

13 4 Scenarium: Proces-orienteret brug af OIO EA 4.1 Situation En myndighed har modificeret sine strategier, og/eller opdaget at de processer der skal understøtte at strategierne realiseres, ikke fungerer effektivt. Der kunne for eksempel være tale om at en større del af sagsbehandlingen lægges ud til den enkelte borger. Borgen skal selv fremfinde og sammenstykke en række oplysninger i en ansøgning, og myndighedens rolle bliver mere at kontrollere, samt at bruge den sparede tid på mere rådgivning. Aktørerne i processerne er ikke tilfredse med den systemunderstøttelse de får i at udføre processerne, samtidig med at it-afdelingen bruger megen tid på at holde systemerne ved lige og kørende. 4.2 Mål og fokus Målet er at få afdækket præcist hvordan situationen opleves set fra forretningssiden, og afbalancere den med hvordan it bruger sine ressourcer på at understøtte forretningen. Hermed kan der afstikkes retningslinier for hvilke procesområder der bør styrkes bedre, med nye applikationer. Det fremtidige mål dokumenteres i en egentlig applikations- og servicearkitektur. Det er et mål hurtigt at få en overordnet retning for den fremtidige forretningsarkitektur, som så kan guide de enkelte forretningsenheder. Det er ikke et mål at lave en detaljeret 3-5 årsplan nu, og ej heller at gå ind i detaljerede workflow-analyser af arbejdsgange. Fokus er afbildet nedenfor: Orientering Organisation Fagbredde Teknologiorienteret Forretningsorienteret Hele organisationen Dele af organisationen Generelt Fagspecifikt Om orientering: Enterprise arkitekturen vil fokusere på forretningsprocesserne og de forretningsorienterede applikationer der fremover skal bruges. Teknologi infrastrukturen vil blive berørt, men primært for at sikre at den kan understøtte de nye applikationer man måtte indføre. Om organisation: fokus er i dette scenarium på de forretningsorienterede dele af organisationen de der leverer de services organisationen tilbyder sine eksterne interessenter. Scenariet kunne dog godt udvides til at omfatte hele applikationsporteføljen administrative systemer og mere infrastrukturorienterede såsom mail og portaler. Om fagbredde: som nævnt ovenfor er det fagsystemerne der er i fokus. 4.3 Rolleovervejelser De roller der er vigtige at få besat er: En forretningsarkitekt, der kan lave en konsolideret beskrivelse af de forretningsprocesser man ønsker at arbejde efter fremover. Forretningsarkitekten og applikationsarkitekten samarbejder om at vurdere hvor god en applikationsunderstøttelse forretningsprocesserne har i dag og fremover. En applikationsarkitekt, der kan skabe overblikket over hvordan det nuværende fagsystemlandskab ser ud. Forretningsarkitekten og applikationsarkitekten samarbejder om at vurdere hvor god en applikationsunderstøttelse forretningsprocesserne har i dag og skal have fremover. På baggrund af dette prioriteres udviklingen og den fremtidige applikations- og servicearkitektur defineres. En enterprise arkitekt, der kan holde overblikket over samtlige de aktiviteter der her foreslås, og sikrer en kontinuitet og at der etableres den bro mellem forretningssidens applikationsbehov og teknologiens implementering af disse. I det videre arbejde med at sikre implementeringen er enterprise arkitekten også en nøgleperson. OIO EA scenarier v1.doc Side 13 af 22 Januar 2007

14 I nogen grad indgår også en teknologiarkitekt, der kan skabe et overblik over den it-infrastruktur der forefindes, og i samarbejde med applikations- og enterprise arkitekterne at designe den it-infrastruktur der skal understøtte den fremtidige applikationsarkitektur. 4.4 Flow og trintilpasninger af OIO EA metoden OIO EA kan i dette scenarium med fordel anvendes sådan: Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. EA governance strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Nuværende arkitektur Fremtidige arkitektur Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Figur 4: Proces-orienteret brug af OIO EA. Her er fokus på at etablere det sammenhængende link fra strategier og mål, over strategiske hovedprocesser og hvilke organisationer/lokationer der udfører disse, og til hvilke applikationer og services der kræves for fremover bedre at understøtte dette. Man kommer sikkert til i noget omfang at interessere sig for hvilken teknologi infrastruktur der skal til for at understøtte den fremtidige applikationsarkitektur. Man kan lave en migreringsstrategi og -plan, eller man kan lade være. I fald man lader være (som på figuren ovenfor), vil de enkelte forretningsenheder skulle forestå projekter selv, og disse vil så i EA governance blive prioriteret og eventuelt modificeret så de støtter den strategiske enterprise arkitektur mest muligt. Forløbet er: A3. Metodegrundlag: 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. A4. Projekt charter: Her dokumenteres helt konkret hvem der deltager i hvilke trin. Arbejdsopgaver og arbejdsgange aftales, og der sikres opbakning omkring enterprise arkitektur projektet. Endvidere fastlægges projektaktiviteter, tidsfrister og ansvarlige for de enkelte trin. Det er vigtigt at konkrete personer udpeges ikke mindst at der sikres en god repræsentation fra forretningssiden, folk der er godt inde i organisationens forretningsprocesser og arbejdsgange. Herefter starter det egentlige projekt. Der tilsigtes en stor grad af parallelitet: 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. C2 applikationsarkitektur (nuværende) vil have størst fokus. Her dokumenteres nuværende OIO EA scenarier v1.doc Side 14 af 22 Januar 2007

15 applikationer og integrationer. Man kan inddrage C3 servicearkitektur (nuværende), hvor man dokumenterer hvilke services organisationen i dag benytter sig af (det er ikke nødvendigvis ret mange). Det er dog nødvendigt at have et vist overblik over C4 teknologiarkitektur (nuværende), til brug for valg af teknologier til de fremtidige applikationer. Hvis muligt vil man typisk basere de fremtidige applikationer på teknologi (udviklingsmiljø, databaser, osv.), hvor organisationen allerede har erfaring og kompetencer. På forretningssiden udfører man følgende trin: A5. Vision, mål og strategier udføres ret hurtigt, og har til formål at opsummere og konsolidere de forretningsorienterede strategier og mål, således at man har et pejlemærke for hvilke applikationer der skal opprioriteres i den nye applikationsarkitektur. Går strategierne for eksempel i retning af mere individuel betjening af borgerne, er det nok CMS- og CRM-systemer man ender med at opprioritere men det vil den senere analyse vise. Det er en god ide at prioritere strategierne. Herefter udføres i parallel: B2. Lokalitioner/organisation, hvor man afdækker hvilke fremtidige lokationer og organisationsstrukturer organisationen har (der ligger ikke noget i scenariet der indikerer at de er anderledes end i dag, så trinet er sikkert hurtigt overstået). B4. Forretningsprocesser: Der ligger ikke noget i scenariebeskrivelsen der indikerer at man har til hensigt at ændre forretningsprocesserne mere at ændrede strategier kan betyde op- og nedprioritering af it-understøttelsen til forretningsprocesserne. Leverancer er: 1. Man dokumenterer forretningsprocesserne (nuværende og fremtidige). Hertil kan man benytte forskellige teknikker BPMN, UML eller lignende. 2. Man kan med fordel mappe forretningsprocesserne ind i strategierne og på baggrund af strategiernes prioritet søge at give en prioritet til forretningsprocesserne: hvilke er vigtigst at sikre understøttes godt med it? 3. Ligeledes kan man mappe forretningsprocesserne imod de nuværende applikationer (fra trin C2). Herved får man et billede af den it-support de enkelte processer får. Man bør på baggrund af denne lave en vurdering af (i) hvor effektiv er it-supporten for de enkelte processer (i brugernes øjne), og (ii) hvad koster denne support per proces (i it drift/vedligehold). Når man holder 2. og 3. sammen, får man et billede af for hvilke forretningsprocesser der skal planlægges end bedre applikationssupport end i dag. Vi er nu klar til at designe den fremtidige arkitektur: C2. Applikationsarkitektur (fremtidig): Man vil her beskrive: Fremtidige applikationer både eksisterende der lever videre i uændret og modificeret form, og nye der foreslås. Endvidere en beskrivelse af hvilke eksisterende der foreslås udfaset, og hvordan de så erstattes. Beskrivelsen vil relatere sig til procesbeskrivelserne, og gerne afdække hvor stor en del af processerne de enkelte applikationer hjælper til at automatisere. En oversigt over integrationer herunder hvilke ny/re-integrationer der foreslås foretaget. Applikationer og integrationer C3. Servicearkitetur (fremtidig): Den fremtidige servicearkitektur vil blive udarbejdet i samspil med leverancerne i C2 og C4. Den resulterer i en kortlægning af hvor de forretningsservices, som B3 identificerede, bedst realiseres både under hvilken infrastruktur, og hvilke applikationer der har brug for hvilke services. Leverancen er: En mapning af hvilke services (B3) der leveres fra hvilke applikationer i dag. C4. Teknologiarkitektur: (stiplet linie). I teknik-aktiviteten kommer man til at lave en oversigt over hvilken fremtidig teknologiarkitektur der skal understøtte fremtidige applikationer og services. De beskrives: Teknologi-oversigt: oversigt over brug af teknologier, teknologikonfigurering af platforme (ABBs arkitektur byggeblokke ), og en oversigt over systemtopologien i de indgående organisationer. OIO EA scenarier v1.doc Side 15 af 22 Januar 2007

16 Den nuværende og fremtidige teknologiarkitektur: en infrastrukturkonsolidering, hvor for eksempel forskellige mailsystemer, netværksteknologier og arbejdsstationskonfigurationer konsolideres. Som et led i Teknikaktiviteten kommer man også til at forholde sig til hvordan man bedst komponentopdeler og service-orienterer den fremtidige arkitektur. Muligvis vil man også skulle tage stilling til en informationsarkitektur, herunder brug af OIOXML og andre offentlige standarder. Herefter fortsætter forløbet med: Y3. EA governance. Den nuværende og fremtidige arkitektur underkastes EA governance rammen, så applikations- og servicearkitekturen kommunikeres, implementeres, men samtidig holdes opdateret OIO EA scenarier v1.doc Side 16 af 22 Januar 2007

17 5 Scenarium: Informations-orienteret brug af OIO EA i en sektor 5.1 Situation Organisationen bruger mange ressourcer på at udveksle data i forskellige formater, at konvertere data, at vaske data mere eller mindre automatisk. Dataudvekslingen sker dels internt, men ikke mindst også med brug af data fra andre myndigheder i sektoren. Typisk vil man bruge en række fællesoffentlige data, såsom CPR-numre, BBR-informationer, informationer fra SKAT, eller lignende. Integrationer mellem applikationer er typisk lavet punktvist, og nyintegrationer er både tidskrævende og giver lille fleksibilitet. Samtidig er kravene til en mere smidig digital forvaltning stigende. Scenariet er komplementær til scenariet om proces-orienteret brug af SOA, med fokus på informationsudveksling frem for proces-integration. 5.2 Mål og fokus Målene omfatter: Standardisering af de forretningsobjekter der udveksles, således at integrationerne kan foretages nemmere. En konsolideret begrebsmodel for forretningsobjekter på tværs af sektoren, der prioriterer standardiseringen, således at de mest anvendte forretningsobjekter også er de der først standardiseres. En konsolidering af betydningen bag de enkelte forretningsobjekter på tværs af en sektor betyder også en homogenisering af disse til gavn både for de myndigheder der skal samarbejde, og for de borgere/virksomheder der modtager information fra myndighederne. Fokus er afbildet nedenfor: Orientering Organisation Fagbredde Teknologiorienteret Forretningsorienteret Hele organisationen Dele af organisationen Generelt Fagspecifikt Om orientering: Enterprise arkitektur-opgaven vil fokusere på de forretningsobjekter der udveksles mellem organisationen og dens samarbejdspartere og med dens kunder. Om organisation: Fokus er på de dele af organisationen, hvor der foretages behandling af sager, der kræver information fra flere myndigheder. Om fagbredde: Fokus er på de mere fagspecifikke dele af organisationens virke. 5.3 Rolleovervejelser De roller der er vigtige at få besat er: En informationsarkitekt, der kan afdække hvilke forretningskritiske objekter der kommunikeres så meget på tværs af sektoren at de med fordel kan, og bør standardiseres. En forretningsarkitekt, der kan sammenfatte de ønsker til de tjenester som den nye organisation skal udbyde til borgere og virksomheder. En applikationsarkitekt, der kan medvirke til at skitsere de tjenester (services) man nu og fremtidig skal levere, med fokus på hvilke informationer der er påkrævede for at levere disse services. Og en enterprise arkitekt, der kan holde overblikket over primært hvilke informationer der kræves for at levere hvilke services, samt at sikre at konklusionerne forankres i en governance struktur. OIO EA scenarier v1.doc Side 17 af 22 Januar 2007

18 5.4 Flow og trin-tilpasninger af OIO EA metoden OIO EA kan i dette scenarium med fordel anvendes sådan: Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. EA governance strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Nuværende arkitektur Fremtidige arkitektur Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Figur 5: Informations-orienteret brug af OIO EA. I dette scenarium er der lagt op til at identificere fælles informationsformater og tilhørende web services der bør være enterprise-wide understøttede på tværs af stat, regioner og kommuner. Det vil sige, at der bliver identificeret fællesoffentlige, multi-sektor og sektor-specifikke OIO-datastandarder og web services. Fokus er på at etablere det sammenhængende link fra strategier og mål, over forretningens centrale begreber forretningsobjekter, og til hvilke services der benytter disse. Man kan lave en migreringsstrategi og -plan, eller man kan lade være. Vi foreslår at der laves en migreringssplan, og de omfattede initiativer vil så i EA governance blive prioriteret og eventuelt modificeret så de støtter den strategiske enterprise arkitektur mest muligt. Forløbet er: A3. Metodegrundlag: 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. A4. Projekt charter: Her dokumenteres helt konkret hvem der deltager i hvilke trin. Arbejdsopgaver og arbejdsgange aftales, og der sikres opbakning omkring enterprise arkitektur projektet. Endvidere fastlægges projektaktiviteter, tidsfrister og ansvarlige for de enkelte trin. Det er vigtigt at konkrete personer udpeges ikke mindst at der sikres en god repræsentation fra forretningssiden, folk der er godt inde i hvilke forretningsobjekter, der er essentielle for arbejdsgangene. Herefter starter det egentlige projekt. Der tilsigtes en stor grad af parallelitet: På forretnings- og tekniksiden vil man straks gå i gang med at få dokumenteret den nuværende (blå pile) brug af forretningsobjekter i trinet B1. Forretningsobjekter (nuværende), efterfulgt af C1. OIO EA scenarier v1.doc Side 18 af 22 Januar 2007

19 Informationsarkitektur (nuværende), hvor man dokumenterer de informationsmodeller (logiske datamodeller) der anvendes i dag. På strategisiden udfører man relativt hurtigt A5. Vision, mål og strategier, med formål at opsummere og konsolidere forretningsorienterede strategier og mål, og hvilke forretningsinformationer der er essentielle for at kunne eksekvere strategierne. Herefter udføres, i interaktion: B1. Forretningsobjekter, hvor der ligger en begrebsafklaring af hvilke forretningsobjekter der fremover vil være centrale for sektoren. Her bør man absolut inddrage det arbejde som sektorens sektorstandardiseringsudvalg (SSU) måtte have udført hidtil. Leverancen i dette trin er en sektorforretningsobjektmodel, der kan variere fra en overordnet model hvor kun forretningsobjekter og eventuelt deres relationer er identificerede, og til en model der mere ligner en egentlig logisk datamodel, med attributter og relationer mere præciserede. B3. Forretningsservices, hvor man identificerer hvilke fremtidige forretningsservices der ønskes, og hvilke forretningsobjekter disse kræver. Fokus er på tværgående forretningsobjekter, hvor en sektorkonsolidering er ønskværdig. Dette tjener også til at validere og give tilbageløb til forretningsobjektmodellen. Herefter kan designes den fremtidige arkitektur: C1. Informationsarkitektur (fremtidig): Man vil her definere og beskrive den informationsmodel logisk datamodel om man vil der er central for sektoren, den fælles datamængde der skal standardiseres. Denne bør både beskrive semantik og syntaks for informationsobjekterne. Den bør videregives til sektorstandardiseringsudvalget, således at en standardisering af forretningsobjekter til OIO-datastandarder kan ske i sektorstandardiseringsudvalgs-regi. C3. Servicearkitetur (fremtidig): Den fremtidige servicearkitektur vil blive udarbejdet i samspil med leverancerne i C1 og B3. Den resulterer i en kortlægning af hvilke informationer (fra C1), som de forretningsservicesder blev identificeret i B3, kræver for at kunne realiseres, og derefter en præcisering af disse services. Herefter fortsætter forløbet med: E2. Migreringsplan. Man vil identificere de konkrete projekter der kan iværksættes for at konsolidere informationsarkitekturen og standardisere på fælles objekter i sektoren. Navnlig bør leverancen fra C1/C3 fødes ind i aktuelle it-projekter (OIO-projekter), således at disse implementerer de udarbejdede OIO-datastandarder for/definitioner af forretningsobjekterne, og bidrager til OIO-standardiseringen af endnu ikke standardiserede objekter. Y3. EA governance. Dette vil i dette tilfælde sige at sikre at den nuværende og fremtidige informationsarkitektur underkastes en EA governance ramme. Det vil her specielt implicere: - At arbejdet med at standardisere og implementere OIO-datastandarder forankres i de(t) relevante sektorstandardiserings-udvalg (SSU). - At det sikres at der sker fremdrift i standardiseringen af forretningsobjekter der endnu ikke er standardiserede. Dette er også normalt forankret i SSUet, samt i de konkrete it-projekter. - At implementeringen af de udviklede standarder og web services forankres via konkrete projekter i de relevante systemer. OIO EA scenarier v1.doc Side 19 af 22 Januar 2007

20 6 Scenarium: Webmasters brug af OIO EA 6.1 Situation Scenariet tager udgangspunkt i denne situation: Kommunen søger at servicere sine borgere også gennem digitale medier og nemmere tilgængelig service. for at kunne levere en hurtigere En webmaster er en essentiel del af dette, idet kommunen gør sine tjenester tilgængelige via en portal på internettet. 6.2 Mål og fokus Kommunale borgerservices på Internettet skal være Let tilgængelige og brugervenlige. Genkendelige og sammenhængende med de øvrige services borgeren behøver. Dette implicerer: Brugerne skal let kunne finde de informationer de søger. Brugerne skal kunne betjene sig selv i højere grad, således at kommunen kan fokusere sine ressourcer på den faglige behandling af sagerne. Der skal være en sikker integration af sagsbehandlingen i kommunen og i andre relevante myndigheder Område Organisation Fagbredde Teknologiorienteret Forretningsorienteret Hele organisationen Dele af organisationen Generelt Fagspecifikt Om orientering: Enterprise arkitektur-opgaven vil i dette scenarium fokusere på teknologidelen, men orienteret mod webservices, ikke traditionel infrastruktur. Processcenariet kan supplere dette, med sit fokus på forretningssuden. Om organisation: fokus er på de dele af organisationen der yder services via web. Om fagbredde: web bruges sandsynligvis både til generelle og til fagspecifikke services, hvorfor der er en bred dækning her. 6.3 Rolleovervejelser Aktørerne nedenfor er essentielle i dette scenarie: Webmaster: Koordinerende rolle i at sikre den udadvendte fremtræden af kommunen (web-sitet) og det faglige indhold herunder at sikre at de services kommunen ønsker at udbyde, implementeres på sitet. Dette i samarbejde med en informationsarkitekt og en forretnings/applikationsarkitekt. Informationsarkitekt: Sikrer at indholdet der kommunikeres (kommunens informationer såvel som borgerens) konsistent kan deles med andre offentlige myndigheder. Forretningsarkitekt/Applikationsarkitekt: Sikrer at de arbejdsgange, som kommune-portalen tilbyder, er overensstemmende med kommunens arbejdsgange, og understøttes af applikationer OIO EA scenarier v1.doc Side 20 af 22 Januar 2007

21 6.4 Flow og trintilpasninger af OIO EA metoden I dette scenarium kan metoden anvendes som vist nedenfor: Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. EA governance strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Nuværende arkitektur Fremtidige arkitektur Figur 6: OIO EA brugt af en webmaster. Trinene kan passende tilpasses på følgende måde (defineres i trin A3): X1: Forretningsmæssige trends: De tendenser der er for digital borgerbetjening i kommuner afdækkes. Her kan hentes inspiration fra både andre danske kommuner, udlandet, KL-publikationer mv. A4: Projekt charter: Opgaven med at udbyde kommunens ydelser over internettet fastlægges i et projekt kommissorium, hvor også ressourcer afsættes. A5: Vision, mål og strategier: Kommunens mål og strategier for digital borgerbetjening konsolideres, som retningsliner for definition af de borgerservices der skal udbydes. A6: It principper: Kommunens generelle principper for brug af it dokumenteres. B3: Forretningsmæssige services: Det er absolut essentielt at få etableret konsensus omkring hvilke services kommunen ønsker udbudt på internet-portalen, og derefter at få disse defineret i præcise termer, med SLAer. Der dokumenteres: De nuværende services. De ønskede fremtidige. Det er vigtigt at få designet hvordan disse services skal spille sammen med andre offentlige services. Derfor vil det være relevant at afdække også de services der ikke direkte leveres af kommunen, men er en del af den samlede borgerbetjening som man ønsker at understøtte. Der udarbejdes C3: Servicearkitetur: Man dokumenterer den nuværende servicearkitektur, og udvikler den fremtidige: hvilke tekniske services skal kommunens web-site betjene sig af, for at kunne levere de forretningsmæssige services defineret i trin B3? Som input til C3 benyttes: A6: It principper man tager organisationens it-principper som input. OIO EA scenarier v1.doc Side 21 af 22 Januar 2007

22 C1: Informationsarkitektur herunder den fremtidige brug af OIOXML standarder C2: Applikationsarkitektur hvilke applikationer skal levere hvilke services? På baggrund af fremtidig servicearkitektur (C3) defineres E2: Migreringsplan: Hvilke projekter skal initieres for at sikre sitets fremtræden og de services man vil udbyde? Hvilke projekter skal initieres for at tilpasse back-office applikationer og dataformater til at kunne supportere de services sitet skal levere? OIO EA scenarier v1.doc Side 22 af 22 Januar 2007