OIO Enterprise Arkitektur Introduktion til OIO Enterprise Arkitektur metoden (OIO ) Version 1.0 Tekniske og forretningsmæssige X1. Forretningsmæssige X2. Tekniske Strategi Forretning Teknik A1. relaterede udfordringer A3. metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. 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. Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Ministeriet for Videnskab, Teknologi og Udvikling Januar 2007
Om dette dokument Dette dokument giver et overblik over OIO metoden og de tanker der ligger bag den. OIO metoden er en pragmatisk tilgang til enterprise arkitektur, baseret på praktiske erfaringer såvel som på gennemprøvet teori. Dokumentet eksemplificerer anvendelser af OIO, og giver en kort oversigt over de trin OIO indeholder. Dokumentet er beregnet til beslutningstagere og it-arkitekter i det offentlige, der ønsker en hurtig indføring i hvad OIO er, og hvordan den kan anvendes. Der findes både online og i andre dokumenter mere detaljerede beskrivelser af de enkelte trin i metoden, af scenarier, af kompetenceprofiler, og andet der kan gavne når man konkret ønsker at anvende metoden. 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 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...3 2 Overblik over OIO Enterprise Arkitektur metoden...4 3 Den røde tråd i OIO...5 3.1 Eksempel: OIO brugt i infrastrukturkonsolidering...6 4 OIO metodens aktiviteter og trin...7 4.1 OIO strategiaktiviteten...7 4.2 OIO forretningsaktiviteten...8 4.3 OIO teknikaktiviteten...8 4.4 OIO gap-analyseaktiviteten...9 4.5 OIO forandringsaktiviteten...9 4.6 Aktivitet X: Tekniske og forretningsmæssige... 10 4.7 Aktivitet Y: Principper og styring... 10 OIO introduktion - v1.doc Side 2 af 11 Januar 2007
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 kaldes en enterprise arkitektur, ofte forkortet. Håndbogen skitserede en fremgangsmåde til at udvikle en sådan enterprise arkitektur, beskrev hvilke overvejelser man burde gøre sig i de enkelte trin, og gav eksempler på hvilke metoder man kunne benytte. Den overordnede reference-metode var den nedenfor afbildede. Figur 1: Håndbogens metode-ramme. Arbejdet med OIO Enterprise Arkitektur metoden har søgt at gøre denne ret generelle ramme mere operationel. Hver af de fem midterste, mørkeblå aktiviteter er blevet brudt ned i 3-6 trin, og disse er blevet systematisk beskrevet. For hver enkelt trin er beskrevet: Formål hvorfor gennemføres trinet, hvordan hjælper det til at realisere en enterprise arkitektur? Aktører hvem deltager typisk i at udføre arbejdet? Input på hvilket grundlag starter man (herunder hvilke output fra hvilke tidligere udførte trin man anvender)? Output hvad vil være produkterne udarbejdet i trinet? Metode (skitseret) hvordan vil en fremgangsmåde typisk være? Gode råd erfaringer der supplerer den korte beskrivelse af metoden. Eksempel der bringes for mange trin et eksempel til at lette forståelsen for hvad output bliver. Referencer til relevante dokumenter og skabeloner, links til dokumenter der kan give inspiration og uddybe den metode der benyttes i det enkelte trin. Herunder også referencer til tilsvarende metodetrin i andre rammeværk og metoder (idet der dog ikke nødvendigvis er en 1:1 overensstemmelse mellem OIO trin og andre metoders). OIO vil findes i en statisk og i en dynamisk version. Den statiske version består af en række dokumenter der omfatter introduktion til OIO, metodetrinbeskrivelser, scenarier og andet. Disse dokumenter kan downloades OIO introduktion - v1.doc Side 3 af 11 Januar 2007
og printes. Den dynamiske version er en interaktiv håndbog med links til andre ressourcer i og udenfor OIO portalen, hvorved den også løbende udbygges med nyt indhold og nye relationer. OIO 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. 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. OIO sætter en ramme for, og vil være tæt integreret tæt med mere detaljerede OIO standarder og vejledninger, f.eks. OIO-kataloget over teknologistandarder, OIOXML datastandarder (Infrastrukturbasen), OIO web services, osv. 2 Overblik over OIO Enterprise Arkitektur metoden OIO er en nedbrydning af håndbogens ramme. Metoden med de enkelte trin indenfor hver aktivitet er afbildet nedenfor: Tekniske og forretningsmæssige X1. Forretningsmæssige X2. Tekniske Strategi Forretning Teknik A1. relaterede udfordringer A3. metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. 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. Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Figur 2: Håndbogens metode udvidet til OIO metoden (klikbar i den online version). OIO introduktion - v1.doc Side 4 af 11 Januar 2007
OIO metoden fokuserer på trinene indenfor de fem centrale aktiviteter (de der er markeret med blåviolet). Altså trinene A1-E3. Trinene X1-X2 samt Y1-Y5 indgår i et samspil med OIO metoden, og er ligeledes beskrevet. De vil dog normalt udføres af andre end de enterprise arkitektur-ansvarlige, med undtagelse af trin Y3, der er central for vedligeholdelse af arkitekturen. Om OIO metoden er der følgende vigtige punkter at bemærke sig: 1. Som også anført i håndbogen: Det en løbende, iterativ proces at udvikle og vedligeholde en Enterprise Arkitektur. 2. OIO er en metode, ikke et arkitekturrammeværk. Man kan for eksempel ikke sammenligne den med Zachman Framework, som er et rammeværk, ikke en metode. Output produceret efter OIO metoden kan naturligvis klassificeres efter OIO rammeværket, Zachman eller andre rammeværker. 3. De enkelte trin udføres ikke i en fastlagt rækkefølge. Nummereringen antyder én, der ofte kan være hensigtsmæssig (idet output fra nogle af trinene er input til andre). Men man kan for eksempel sagtens udføre B5 og B6 før man laver B1-B4. Ligeledes vil man ofte udføre dokumentationen af den nuværende arkitektur i trin C1-C4 i parallel med B-trinene, for så, når begge foreligger, designe den fremtidige teknik-arkitektur også i trin C1-C4. 4. Ligeledes kan man (og vil ofte) udføre flere trin i parallel for eksempel nuværende arkitektur delen af trin C1-C4 paralleliseres ofte. Selv hvor man ikke gør dette, vil man kunne opleve at et trin kan give anledning til tilbageløb, hvor man modificerer output fra tidligere trin. 5. Man udfører kun sjældent alle trin i OIO metoden, man tilpasser den efter behovet. Man kan eksempelvis vælge at fokusere på infrastruktur-konsolidering, hvor for eksempel dele af C1 og hele C4 så vil være centrale. Eller man kan for eksempel vælge at fokusere på proces-optimering, hvor så B3/B4 samt C2/C3 vil være nøgletrin at gennemføre. Kapitel 3 eksemplificerer hvordan OIO med fordel kan anvendes i et givet scenarium. Separat (i et dokument og online) beskrives andre hyppige scenarier. 6. Inden for hvert trin udfører man ligeledes ikke altid alle leverancer. For eksempel indeholder C1. Informationsarkitektur to hoveddele: C1.1 beskriver den logiske datamodel som en udvidelse og detaljering af B1 s forretningsobjektmodel. C1.2-3 beskriver lokationer og dataflows imellem fysiske databaser der implementer B1/C1.1. Man vil kunne lave disse to ret uafhængigt af hinanden, begge baseret på input fra B1. 7. Det er ikke et mål i sig selv at lave Enterprise Arkitektur arbejde. Heraf følger at man med fordel kan fokusere på de områder der med mindst nødvendig indsats giver de mest rigtige svar til hvordan teknologi skal anvendes til at opnå de ønskede forretningsmål. 8. arkitekten er en gennemgående aktør i alle trin. Ikke nødvendigvis som den drivende kræft i alle trin, men for at sikre konsistens på tværs, og identificere synergimuligheder hvor relevant. I tilfælde af inkonsistens mellem leverancer (eksempelvis at den foreslåede teknologiarkitektur ikke understøtter den fremtidige applikationsarkitektur) skal arkitekten søge at løse dette. Typisk vil man samle de arkitekter der har udarbejdet leverancerne, og se om ikke der kan afdækkes en brugbar løsning. Når man påbegynder et projekt, der sigter mod at etablere eller modificere en Enterprise Arkitektur, fastlægger man altså den specifikke brug af OIO metoden, sådan som punkt 3.-6. angiver. 3 Den røde tråd i OIO OIO 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 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 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 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. OIO introduktion - v1.doc Side 5 af 11 Januar 2007
3.1 Eksempel: OIO 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 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. relaterede udfordringer A3. metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A2. strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migrationsstrategi E2. Migrationsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Nuværende arkitektur Fremtidige arkitektur Figur 3: OIO brugt i infrastrukturkonsolidering. Man vil starte med i A3 at præcisere OIO 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, etc.), men kun for at sikre at man kender OIO introduktion - v1.doc Side 6 af 11 Januar 2007
fremtidige applikationers og services forventninger til den fremtidige infrastruktur netværksstruktur, osv. udviklingsmiljøer, 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. 4 OIO metodens aktiviteter og trin Hver enkelt blåviolet kasse betegner en aktivitet. Inden for hver kasse er der flere trin, og hver enkelt trin kan føre til forskellige leverancer, også kaldet OIO produkter. En oversigt over mulige OIO aktiviteter og trin gives nedenfor. 4.1 OIO strategiaktiviteten Strategiaktivitetens mål er at sikre at enterprise arkitekturen forankres i forretningens behov. Strategi A1. relaterede udfordringer A3. metodegrundlag A5. Vision, mål og strategier A2. strategi A4. Projekt charter A6. It-principper Figur 4: OIO metoden Strategi. De grå trin er opstartsaktiviteter, der udføres for at etablere grundlaget for OIO arbejdet. A1 afdækker hvilke udfordringer problemer og muligheder OIO skal adressere. A2 adresserer allerede fra starten af et projekt hvordan arkitekturen kan realiseres i den givne organisation, og påbegynder mobiliseringen af en struktur. A3 tillemper den generelle OIO metode til organisationens behov i et konkret enterprise arkitekturforløb. Dvs. definerer hvilke trin der skal udelades, og konkretiserer indholdet af de trin der udføres. A4 opstiller så projekters rammer, med input fra A1-A3. Dette bliver en projekthåndbog for projektets deltagere. Trin A1-A4 sætter altså rammerne for OIO projektet, og de følgende trin fastlægger de strategiske rammer for fortsættelsen: A5 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. OIO introduktion - v1.doc Side 7 af 11 Januar 2007
A6 definer de it-principper som organisationen bekender sig til, og som sætter retningslinierne for teknologivalg senere. 4.2 OIO forretningsaktiviteten 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 operationen. Forretning B1. Forretningsobjekter B3. Forretningsservices B5. UseCases B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow Figur 5: OIO metoden Forretning. De enkelte trin kan udføres i forskellig rækkefølge, herunder også i parallel: B1 identificerer de begreber eller forretningsmæssige objekter der anvendes af forretningssiden i organisationen såsom: borger, henvendelse, areal, bygning etc. B2 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. B3 beskriver de forretningsmæssige services som organisationen tilbyder sin omverden firmaer, kunder, etc. borgere, B4 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. B5 beskriver Use Cases altså hvilke opgaver hvilke aktører løser hvordan. Fokus er på hvad der udføres, ikke hvordan. B6 konkretiserer B5 ved at beskrive mere operationelt hvordan de enkelte opgaver løses. 4.3 OIO teknikaktiviteten Teknik-aktivitetens mål er at sikre at den nuværende teknik-arkitektur dokumenteres, og at den fremtidige (3-5 år ud i fremtiden) arkitektur bliver defineret. Både den nuværende og den fremtidige arkitektur defineres indenfor fire områder: Teknik C1. Informationsarkitektur C3. Servicearkitektur C2. Applikationsarkitektur C4. Teknologiarkitektur Figur 6: OIO metoden Teknik. De enkelte trin er: OIO introduktion - v1.doc Side 8 af 11 Januar 2007
C1 dokumenterer den nuværende, og designer den fremtidige informationsarkitektur. Begge omfatter logiske datamodeller og fysiske database strukturer og data distributionsskemaer. C2 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. C2 beskriver også hvordan applikationerne bruges, og hvilke informationer de genererer og bruger men derimod ikke hvordan applikationerne konstrueres. C3 komplementerer C2, 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. C4 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). 4.4 OIO gap-analyseaktiviteten -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. D1. Restriktioner D2. Muligheder D3. De enkelte trin er: Figur 7: OIO metoden. D1 giver en oversigt over restriktioner, der skal tages højde for i en migrationsplan. D2 afdækker muligheder (projektforslag) der gavner virksomheden forretningsmæssigt, teknisk eller økonomisk. D3 analyserer forskellene mellem den nuværende og den fremtidige arkitektur, som et grundlag for at lave en migrationsplan. 4.5 OIO forandringsaktiviteten Forandrings-aktivitetens mål er at sikre at den fremtidige Entreprise Arkitektur realiseres. OIO introduktion - v1.doc Side 9 af 11 Januar 2007
Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse De enkelte trin er: Figur 8: OIO metoden Forandring. E1 tilvejebringer overordnede retningslinier for hvordan en migrering til det ønskede fremtidige itlandskab kan realiseres. E2 realiserer disse til en konkret plan, der identificerer og i en vis detaljeringsgrad beskriver større it projekter de næste 3-5 år. E3 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. 4.6 Aktivitet X: Tekniske og forretningsmæssige X-aktiviteten indeholder trin der berører behøver) at tage højde for. det vil sige muligheder som organisationen kan (men ikke Tekniske og forretningsmæssige X1. Forretningsmæssige X2. Tekniske De enkelte trin er: Figur 9: OIO metoden Tekniske og forretningsmæssige. X1 giver input i form af et overblik over hvilke forretningsmæssige tendenser der bør overvejes tænkt ind i enterprise arkitekturen. X1 giver input i form af et overblik over hvilke tekniske tendenser der bør overvejes tænkt ind i enterprise arkitekturen. 4.7 Aktivitet Y: Principper og styring Y- aktiviteten indeholder trin der berører alle de styringsmekanismer der er og givne rammer der er, omkring lovmæssige og kontraktuelle forhold, og omkring budget- og driftsstyring. Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Figur 10: OIO metoden Principper og styring. De enkelte trin er: OIO introduktion - v1.doc Side 10 af 11 Januar 2007
Y1 indeholder de aktiviteter der holder den løbende drift af it-systemerne i gang. Dokumentationen herfra omfatter driftsmanualer, procedurer for at håndtere it-brugerhenvendelser og lignende. Y2 beskæftiger sig med styring af ressourcer og budgetter der blandt andet skal sikre at enterprise arkitekturen implementeres. Y3 er central i -sammenhæng, idet den etablerer en struktur og processer, der kan sikre at enterprise arkitekturen holdes levende og løbende opdateres, kommunikeres og anvendes. Y4 giver et overblik over de lovmæssige bindinger der skal tænkes ind i enterprise arkitekturen. Y5 giver et overblik over de kontraktmæssige forpligtigelser der kan påvirke planen for realiseringen af enterprise arkitekturen. OIO introduktion - v1.doc Side 11 af 11 Januar 2007