OIO Enterprise Arkitektur

Transkript

1 OIO Enterprise Arkitektur De enkelte trin i OIO Enterprise Arkitektur metoden (OIO EA) 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 Gap analyse E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Gap analyse 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 Februar 2007

2 Om dette dokument Dette dokument gennemgår de enkelte trin i OIO EA metoden. OIO EA metoden er en pragmatisk tilgang til enterprise arkitektur, baseret på praktiske erfaringer såvel som på gennemprøvet teori. Dokumentet eksemplificerer også anvendelser af OIO EA, og relaterer den til andre arkitekturmetoder og -rammeværk der måtte være læseren bekendt. Dokumentet er beregnet til arkitekter (herunder enterprise- og it-arkitekter), projektledere, og fagspecialister (både på forretningssiden og indenfor teknik) der ønsker en samlet oversigt over trinene i OIO EA metoden. OIO Enterprise Arkitektur dokumentsamlingen omfatter (februar 2007) 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 roller 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 Overblik over OIO Enterprise Arkitektur metoden Om trinbeskrivelserne Aktivitet A: Strategi A1. EA-relaterede udfordringer A2. EA governance strategi A3. EA metodegrundlag A4. EA projekt charter A5. Vision, mål og strategier A6. It-principper Aktivitet B: Forretning B1. Forretningsobjekter B2. Lokationer/organisation B3. Forretningsservices B4. Forretningsprocesser B5. Use Cases B6. Workflow Aktivitet C: Teknologi C1. Informationsarkitektur C2. Applikationsarkitektur OIO EA trinbeskrivelser v1.0 Side 2 af 71 Februar 2007

3 5.3 C3. Servicearkitektur C4. Teknologiarkitektur Aktivitet D: Gap analyse D1. Restriktioner D2. Muligheder D3. GAP analyse Aktivitet E: Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvensanalyse Aktivitet X: Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Aktivitet Y: Principper og styring Y1. Driftssituation Y2. Budget og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold OIO EA trinbeskrivelser v1.0 Side 3 af 71 Februar 2007

4 1 Overblik over OIO Enterprise Arkitektur metoden OIO EA er en nedbrydning af håndbogens EA ramme. De enkelte trin indenfor hver aktivitet er anført 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 Gap analyse E1. Migrationsstrategi E2. Migrationsplan E3. Konsekvensanalyse D1. Restriktioner D2. Muligheder D3. Gap analyse 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. OIO EA metoden fokuserer på trinene indenfor de fem centrale aktiviteter, de der er markeret med blåt. Altså trinene A1-E3. Trinene X1-X2 samt Y1-Y5 indgår i et samspil med OIO EA metoden, og er ligeledes beskrevet. De vil dog normalt udføres af andre end de enterprise arkitektur-ansvarlige, med undtagelse af trin Y3 EA governance, der er central for vedligeholdelse af arkitekturen. Om OIO EA metoden er der følgende vigtige punkter at bemærke sig: 1. Som også anført i håndbogen: Det er en løbende, iterativ proces at udvikle og vedligeholde en enterprise arkitektur. 2. OIO EA er en metode, ikke et arkitekturrammeværk. Man kan for eksempel ikke sammenligne den med Zachmans Framework, som er en klassifikationsramme, ikke en metode. Output produceret efter OIO EA metoden kan klassificeres efter OIO arkitektur klassifikationsrammen eller andre rammeværker. 3. Der er ikke nogen fastlagt rækkefølge i hvornår de enkelte trin udføres. 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. 4. Ligeledes kan man (og vil ofte) udføre flere trin i parallel. Selv hvor man ikke gør dette, vil man kunne opleve at et trin kan give anledning til tilbageløb, hvor man modificerer tidligere trin. 5. Man udfører kun sjældent alle trin i metoden, man tilpasser den efter behovet. Man kan eksempelvis vælge at fokusere på infrastruktur-konsolidering, hvor for hele C4 så vil være central. Eller man kan for OIO EA trinbeskrivelser v1.0 Side 4 af 71 Februar 2007

5 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 beskriver hvordan OIO EA med fordel kan anvendes i forskellige scenarier. 6. Inden for hvert trin udfører man ligeledes ikke altid alle leverancer. For eksempel indeholder C1. Informationsarkitektur to hovedprodukter (output): C1.1 beskriver en logisk datamodel, som en udvidelse og detaljering af B1 s forretningsobjektmodel. C1.2-C1.3 beskriver lokationer og dataflows imellem fysiske databaser der implementer B1/C1a. 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, og man bør fokusere på de områder der med mindst indsats giver de mest rigtige svar til hvordan teknologi skal anvendes til at opnå forretningsmål. 8. EA arkitekten er en gennemgående aktør i alle trin. Ikke nødvendigvis som 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 EA 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 EA arbejde (ét EA projekt der sigter mod at etablere eller modificere en enterprise arkitektur) fastlægger man altså den specifikke brug af OIO EA metoden, sådan som punkt angiver. OIO EA trinbeskrivelser v1.0 Side 5 af 71 Februar 2007

6 2 Om trinbeskrivelserne Hvert trin i OIO EA metoden er beskrevet fuldstændigt systematisk og ens, med følgende punkter: 1. Formål hvorfor udføre trinet? 2. Aktører hvem indgår? 3. Input hvilke leverancer fra andre trin og andetsteds ligger til grund for arbejdet? 4. Output hvilke leverancer produceres i trinet? 5. Metode indikation af hvilke fremgangsmåder man kan benytte. 6. Gode råd en række opmærksomhedspunkter og andet der hjælper i arbejdet. 7. Eksempler for mange trin er angivet et eksempel på output. Der er endvidere i den dynamiske, online udgave af OIO EA metoden følgende afsnit, med links der løbende bliver opdateret: 8. Relevante dokumenter i OIO Arkitekturbiblioteket links til dokumenter der har indhold svarende til output fra det pågældende trin. 9. Skabelon links til relevante skabeloner. 10. Relation til andre metoder links der viser hvordan trinets metode og output svarer til andre arkitekturmetoder og arkitekturrammeværk. 11. Links yderligere relevante links der kan understøtte arbejdet i trinet. OIO EA trinbeskrivelser v1.0 Side 6 af 71 Februar 2007

7 3 Aktivitet A: Strategi 3.1 A1. EA-relaterede udfordringer Trinet identificerer de væsentligste udfordringer som organisationen står overfor, og som er tværgående og dermed omfattet af en enterprise arkitektur Formål Trinet identificerer de væsentligste udfordringer som organisationen står overfor, og som er tværgående og dermed omfattet af en enterprise arkitektur. En udfordring kan være et problem der skal løses, eller en mulighed man ønsker at udnytte. Trinet afstikker nogle klare retningslinier for hvad arkitekturen overordnet skal adressere; arkitekturens succeskriterier om man vil Aktører EA arkitekt Forretningsarkitekt (it-forretningskonsulent) It-chef, udvalgte brugere og teknikere Forretningsledelsen Input X1. Forretningsmæssige trends, X2. Tekniske trends Y1. Driftssituation, Y2. Budget- og resourcestyring, Y4. Lovmæssige bindinger, Y5. Kontrakt og aftaleforhold Interview/workshop med udvalgte brugere og teknikere, for begges vedkommende både ledere og områdeeksperter Output A1.1 EA-relaterede udfordringer et dokument der kan omfatte En oversigt over de identificerede udfordringer, gerne med prioriteter. Gerne en indikation af hver udfordrings natur (teknisk, forretningsmæssigt). Hvem berøres af et problem? Hvad er konsekvenserne af et problem tid/penge/kvalitet? Hvem kan få gavn af en mulighed? Hvad kan gevinsten være ved at udnytte en mulighed i tid/penge/kvalitet? Metode Det er vigtigt at tænke enterprise når man identificerer udfordringer. Et problem eller en mulighed der vedrører en enkelt, mindre organisatorisk enhed, og som kan adresseres isoleret, og uden at det får konsekvenser for øvrige beslutninger, er ikke en EA udfordring. Det er også vigtigt at komme hele raden rundt. Problemerne kan være af: Forretningsmæssig natur: dårlig og langsom service, ufuldstændigt beslutningsgrundlag, mv. Teknisk natur: ustabil og dyr driftssituation, store vedligeholdelsesomkostninger, mv. Mulighederne for at opnå forbedringer gennem implementeringen af en enterprise arkitektur vil typisk være et miks af fire dimensioner: Strategisk; bedre borger- og virksomhedsfokus. Information; bedre beslutningsgrundlag. Transaktion; lavere pris per forretningstransaktion Infrastruktur; besparelser via infrastruktur-konsolidering og standardisering. OIO EA trinbeskrivelser v1.0 Side 7 af 71 Februar 2007

8 Det er vigtigt at få scannet bredt rundt i organisationen, for at få alle relevante problemer og muligheder med. Det er ligeledes vigtigt at få flere vurderinger af hvor store problemerne og mulighederne er; der kan eksempelvis ofte være stor forskel på hvordan it- og forretningssiden opfatter dette. I kvantificeringen af udfordringerne (omfang/vigtighed at få løst, prioritet) vil man med fordel kunne samle alle der har bidraget til problemoversigten, og lade dem stemme om prioriteterne (evt. vha. group-software) Gode råd Man vil typisk få en lang liste af problemer og muligheder, som med fordel kan grupperes i beslægtede områder Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 8 af 71 Februar 2007

9 3.2 A2. EA governance strategi Trinet sigter mod, fra start, at opstille rammer der skal sikre at enterprise arkitekturen kan realiseres, at nøgle-aktører tages i ed og involveres, og at der sikres et kontinuerligt forløb efter at et EA projekt har defineret enterprise arkitekturen Formål Trinet sigter mod, fra start, at opstille rammer der skal sikre at enterprise arkitekturen kan realiseres, at nøgleaktører tages i ed og involveres, og at der sikres et kontinuerligt forløb, efter at et EA projekt har defineret enterprise arkitekturen Aktører EA arkitekt It-chef Nøgleaktører i organisationen Input X1. Forretningsmæssige trends, X2. Tekniske trends A1. EA-relaterede udfordringer Interview med udvalgte brugere og teknikere Output A2.1 EA governance strategi et dokument der typisk omfatter: Identifikation af økonomiske, organisatoriske og andre rammer for hvordan en enterprise arkitektur kan implementeres i organisationen. Identifikation af nøgle-aktører, herunder beslutningstagere for forskellige it-relaterede beslutninger. Dermed bliver disse involverede allerede fra start. Ovenstående punkt kan med fordel udvides til en egentlig interessentanalyse. Denne giver et overblik over alle interessenter i EA (også de der ikke aktivt indgår i at udvikle EA), deres respektive interesser, og planlægger aktivt deres involvering i EA forløbet. Strategier og kritiske succesfaktorer for EA governance. Identifikation og foreløbig beskrivelse af de strukturer og processer der skal etableres Metode Det tilrådes, at EA governance strategien udvikles i tæt samarbejde med de aktører der senere hen kommer til at stå som ejere af forskellige dele af enterprise arkitekturen. Det er altså vigtigt at skitsere og påbegynde etableringen af de EA governance organisationsstrukturer og -processer der endeligt etableres i trin Y3. EA governance. I dette trin skal man overveje hvilken beslutnings- og kontrol-struktur der bedst kan føre arkitekturen ud i livet (herunder hvilken grad af pisk versus gulerod man ønsker). Blandt de forskellige EA governance modeller er: Forretnings-centreret, centralistisk topstyret (en tværgående gruppe af forretningsledere). Forretnings-centreret, decentral (hver enkelt forretningsenhed bestemmer). It-centreret (it-afdelingen driver EA arbejdet). Anarkistisk (de enkelte aktører bruger EA som vejledning som de lyster). I valg af den mest egnede må man naturligvis overveje organisationens natur. Det vil være en god ide at rådføre sig med, og sikre tidlig involvering af de personer, der senere vil skulle indgå i EA styregruppe, EA Review Board og som EA (chef)arkitekt se trin Y3. EA governance. På baggrund af disse overvejelser dokumenterer man de punkter der er beskrevet i output sektionen ovenfor. OIO EA trinbeskrivelser v1.0 Side 9 af 71 Februar 2007

10 3.2.6 Gode råd Det er vigtigt at have en høj grad af realitetssans i denne aktivitet. Det er langt bedre at etablere en simpel struktur, der har en god chance for at sikre at 80% af EA realiseres effektivt, end en kompleks struktur der aldrig kommer til at virke. Realisering af EA vil som oftest være en iterativ proces, hvor organisationens inddragelse og brug af/overholdelse af EA gradvist øges Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. OIO EA trinbeskrivelser v1.0 Side 10 af 71 Februar 2007

11 3.3 A3. EA metodegrundlag Trinet sikrer at den generelle OIO EA metode tillempes de behov den enkelte organisation har Formål Trinet sikrer at den generelle OIO EA metode tillempes de behov den enkelte organisation har. Det vil sige, der udelades trin der enten ikke er nødvendige, eller hvor der allerede findes arbejde, og at andre trin modificeres hvis det giver mere mening Aktører EA arkitekt Input A1. EA-relaterede udfordringer, A2. EA governance strategi, A4. EA projektcharter Y3. EA governance Output A3.1 OIO EA metode (tilpasset). Dette dokument: En tilpasset OIO EA metode, der indpasser behovene til den enkelte organisations behov. Denne beskrives kort, og indarbejdes i projektcharteret (trin A4). Valg af modelleringssprog og værktøjer der anvendes i projektets enkelte trin Metode Det er vigtigt at være opmærksom på at OIO EA metoden er en ramme der altid tillempes det konkrete behov ikke en opskrift der slavisk skal følges fra ende til anden. Det er vanskeligt at forklare hvordan tillempningen af OIO EA gøres; der kræves meget erfaring for at kunne lave en tillempning der optimerer udbyttet på minimal tid. Man kan dog sige at nogle fornuftige trin at gennemgå vil være: At få fastlagt omfang af EA arkitekturen (i samspil med A4), på to leder: o - horisontalt (skal hele OIO EA metodegennemløbet gennemløbes, eller kun udvalgte trin?) o - vertikalt (skal EA udvikles for hele organisationen, eller kun for udvalgte forretningsenheder/forretningsprocesser?) Konklusion på omfang: hvilket OIO EA trin er relevante i forløbet; hvilke ikke? Skal der andre aktiviteter med der ikke er en del af OIO EA rammen? For de relevante trin der vælges udført: hvilket beslægtet input eksisterer allerede, og i hvilket omfang kan dette genbruges? Herudfra: for de enkelte trin der anvendes: hvilke leverancer skal udelades og hvilke tilføjes? Det er vigtigt at sætte et rimeligt ambitionsniveau det giver ikke mening at gøre arkitekturen så detaljeret at den nærmest er uaktuel når man er færdig - så hellere udvikle den i iterationer. Aktiviteten foregår i parallel med A Gode råd En virkelig erfaren EA arkitekt er essentiel for at sikre at man kun udfører de trin der virkelig hjælper organisationen videre. Der er ofte store besparelser i mand-timer og kalendertid at hente ved at skræddersy metoden til de egentlige behov. Undgå et for højt ambitionsniveau fra starten når omfanget af EA arkitekturen fastlægges. Det er let at komme til at vælge for mange trin lav hellere en hurtig første iteration, og tilføj enten løbende nye trinelementer når behovet viser sig, eller ved næste iteration. OIO EA trinbeskrivelser v1.0 Side 11 af 71 Februar 2007

12 3.3.7 Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 12 af 71 Februar 2007

13 3.4 A4. EA projekt charter Trinet sikrer at formålet med at udarbejde en enterprise arkitektur fastlægges og forankres, og at de nærmere rammer for projektet fastlægges Formål Trinet sikrer at formålet med at udarbejde en enterprise arkitektur fastlægges og forankres, og at de nærmere rammer for projektet fastlægges Aktører EA arkitekt Projektleder Nøglemedarbejdere indenfor it og forretningen Input A1. EA-relaterede udfordringer, A2. EA governance strategi, A3. EA metodegrundlag Y3. EA governance Output A4.1 EA projekt charter. Dette charter (eller kommissorium) kan omfatte: Mål, strategi og kritiske succesfaktorer for enterprise arkitekturen ikke for organisationen som sådan. Dette baseres på A2. Omfang af EA arkitekturen (som defineret i A3) med to dimensioner: horisontalt (hele OIO EA metoden gennemløbes, eller kun udvalgte trin). Vertikalt (EA udvikles for hele organisationen, eller kun for udvalgte forretningsenheder/forretningsprocesser). Projektorganisation, roller og arbejdsgange i EA projektet (for rapportering, godkendelse af leverancer, løsning af issues, timeregnskab, etc.). Valg af værktøjer, dokumentationsformat og -struktur. Forventede gevinster (hertil bør overvejelserne fra A2 indgå). Projektplan med aktiviteter med navngivne personer, leverancedatoer, etc. Trinet foregår i parallel med A Metode Her betjener man sig af almindelig projektledelsesteknikker og principperne i PMI kan for eksempel anvendes. planlægning af projekter. Metoder såsom Prince2 Det er vigtigt at projekt charteret identificerer en executive sponsor af EA aktiviteten. Denne vil typisk indgå i en styregruppe, der træffer fundamentale beslutninger, og som også gerne fortsætter som governance ansvarlige. Det er derfor vigtigt at trin A2 indarbejdes i dette trin, og at man løbende i det projektforløb der kommer ud af dette trin, har indarbejdet hvordan overgangen til en EA governance (trin Y3. EA governance) sker. Aktivitets- og leverancelisten for EA projektet kommer ud af trin A3, hvor den generelle OIO EA metode (trin A5-E3 tillempes til det konkrete behov) Gode råd Det er vigtigt ikke blot at planlægge de tekniske aktiviteter, men også de aktiviteter der sikrer at EA-arbejdet kommunikeres og synliggøres undervejs i forløbet. Dette dels fordi arkitekterne vil have brug for bistand fra en lang række mennesker i organisationen for at nå frem til en god EA, og dels for at forberede indførelsen af EA governance. OIO EA trinbeskrivelser v1.0 Side 13 af 71 Februar 2007

14 3.4.7 Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 14 af 71 Februar 2007

15 3.5 A5. Vision, mål og strategier Trinet konsoliderer organisationens forretningsmæssige side vision, mål, strategier, og analyserer hvilke kritiske succesfaktorer, der har afgørende betydning for målene og strategierne realiseres Formål Trinet konsoliderer organisationens forretningsmæssige side vision, mål, strategier, og analyserer hvilke kritiske succesfaktorer, der har afgørende betydning for at målene og strategierne realiseres. Der udvikles ingen nye mål og strategi i dette trin. Formålet er at sikre at efterfølgende EA aktiviteter er forankrede hos, og i overensstemmelse med forretningens behov Aktører EA arkitekt Forretningsarkitekt Forretningssiden Input X1. Forretningsmæssige trends, X2. Tekniske trends Y2 Budget- og resourcestyring Interviews/workshops med forretningen Output Output kan omfatte: A5.1 Vision, mål, strategier. A5.1 Kritiske succesfaktorer (KSF). A5.2 Metrikker (målepunkter) på de ovenstående f.eks. KPIs (key performance indicators). A5.3 SWOT, business drivers, 5 forces. En analyse af organisationens styrker, svagheder, muligheder og trusler (SWOT-analyse). En analyse af de kræfter der influerer på organisationen (hvori X1 og X2 kan indgå, men også andre, såsom borgernes forventninger). A5.3 Interessentanalyse hvilke væsentlige spillere har hvilke interesser? A5.4 Forretningsregler mere detaljerede, operationelle regler for forretningens virke Metode En typisk tilgang kunne være: Indsamling af hvad der foreligger af strategiske forretningsplaner og andre strategiske dokumenter for organisationen. Interviews med ledere fra de organisatoriske enheder der har ønsker til en EA herunder deres holdning til de foreliggende strategi-dokumenter (meget i sådanne kan ofte være forældet), og indsamling af deres prioriteter. Konsolidering af det modtagne input til et oplæg der bedst muligt afspejler den samlede organisations syn på vision, mål, strategier, mv. Verifikation og justering af denne konsolidering, typisk gennem en workshop. Topledelsen bør være repræsenteret her, således at den konsensus der opnås afspejler et balanceret syn på forretningen, og dermed forankrer EA indsatsen. Det er vigtigt at understrege at dette ikke er management konsulentvirksomhed: Der udvikles ikke nye mål og strategier, men de eksisterende konsolideres således, at der er et fælles referencepunkt. Det er også vigtigt at indse, at man næppe skal forvente total enighed imellem forretningens beslutningstagere det ligger i sagens natur, at de forskellige enheder tit vil have forskelligt fokus og prioriteter. I fald man laver en interessentanalyse, bør man for hver interessent analysere og beskrive: OIO EA trinbeskrivelser v1.0 Side 15 af 71 Februar 2007

16 Interessentens rolle (leverandør til projekt, bruger af løsning, sponsor,...) Interessentens behov (der kan være flere) Hvordan kan interessenten påvirke (positivt og negativt) en planlagt ændring? Hvordan kan interessentens behov løses og er der flere måder at løse et behov på? Interessentens relation til andre interessenter Konkrete navne på kontaktpersoner der skal indgå Evt.: hvor vigtigt er det at imødekomme interessentens behov, relativt til andre interessenter. Man kan passende starte med at tale med organisationens forretnings- og teknik-side, og høre disse hvem der er deres interne og eksterne interessenter, og så tale med dem, for at få konfirmeret, at man har fanget ovenstående punkter korrekt. En interessent kan have flere modsatrettede behov, og man bør afdække om hvilke alternativer der er til at løse et behov. Man bør også søge at begrænse sig til de væsentligste interessenter Gode råd Dette skal ikke være en alt for omfattende aktivitet der er ikke tale om at lave nye strategier, men om at konsolidere det eksisterende. Det er imidlertid essentielt, at forretningssiden kan godtage den konsolidering der er foretaget, og dermed er klar til at støtte at enterprise arkitekturen videreudvikles efter de udstukne retningslinier. Forskellen på dette trin og A3/A4 er, at her fokuseres på den primære målgruppe: forretningssiden. Hermed demonstreres at enterprise arkitekturen er forankret i en forretningsmæssig forståelse. En kritisk succesfaktor er en tilstand eller evne, der hvis den forefindes i organisationen sandsynliggører at organisationen kan lykkes med sine strategier og derved nå sine mål. Et eksempel kunne være: hurtigt at kunne se patientens samlede behandlingsforløb indenfor de sidste 5 år således at en strategi om at kunne tilbyde proaktiv behandling kan lykkedes, og et mål om bedre patienttilfredshed og kortere indlæggelsesperiode dermed opfyldes Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Forretningsstrategiske målsætninger ToldSkats principper for IT-arkitektur understøtter følgende prioriterede strategiske mål fra ToldSkats forretningsstrategier, og de krav, der generelt stilles til den offentlige administration: 1. Omstillingsparathed Det er et mål, at ny lovgivning og nye effektive arbejdsgange kan IT-understøttes med kort varsel, uden at øge IT-omkostninger og -risiko væsentligt. IT-løsninger skal derfor bygges og vedligeholdes på en måde, så det er hurtigt, billigt og sikkert at ændre i dem. 2. Effektive processer ToldSkat konkurrerer og samarbejder med andre myndigheder om etablering af mere effektive arbejdsprocesser jf. skatteministeriets effektiviseringsstrategi. Via regelforenkling m.v. skal arbejdsgange harmoniseres, digitaliseres, centraliseres og eventuelt udliciteres både på tværs af ToldSkat, på tværs af myndigheder, og sammen med den private sektor. IT-systemerne skal let kunne understøtte, at processer bliver ændret og kombineret på tværs af organisatoriske grænser og ITsystemer. 3. Kundeforenkling Det er et mål, at dansk erhvervsliv får færre administrative byrder. Det skal bl.a. realiseres via mere automatisk indberetning; mange adgange for virksomhederne til ToldSkats IT-løsninger bl.a. kombineret med andre offentlige eller private løsninger; mulighed for klar besked så sager gøres OIO EA trinbeskrivelser v1.0 Side 16 af 71 Februar 2007

17 færdige ved første henvendelse. Det kræver bl.a., at grænseflader til IT-systemernes funktionalitet er standardiseret, så den sikkert kan tilgås mange steder, og så den kan kombineres med funktionalitet fra andre IT-systemer. 4. Kundeincitamenter Det er et mål, at det skal kunne betale sig at følge den offentlige regulering, og at benytte effektiv digital kommunikation med det offentlige. ToldSkats indsatsstrategi foreskriver ligeledes, at ToldSkat skal vurdere og betjene hver virksomhed samlet efter disse kriterier. Det kræver mulighed for, at man IT-mæssigt kan analysere alle oplysninger om den enkelte virksomhed. 5. Markedspriser De kommende års pres på de offentlige ressourcer stiller krav om en effektiv offentlig sektor, hvor ydelser udliciteres og indkøbes til markedspriser. Der skal bl.a. skabes stærkere konkurrence om ToldSkats IT-ydelser. Dette kræver, at IT-arkitekturen er så enkel og veldokumenteret, at flere leverandører kan byde på IT-opgaverne, og at IT-systemerne er opdelt, så de kan udliciteres med de arbejdsopgaver de understøtter. OIO EA trinbeskrivelser v1.0 Side 17 af 71 Februar 2007

18 3.6 A6. It-principper Trinet udarbejder it principper, herunder arkitektur principper, med rationale for disse, og der analyseres hvilke konsekvenser disse har Formål Trinet udarbejder it principper, herunder arkitektur principper, med rationale for disse, og der analyseres hvilke konsekvenser disse har. Dette tjener til at udstikke overordnede retningslinjer for det videre EA design arbejde Aktører EA arkitekt (Informationsarkitekt) (Applikationsarkitekt) (Teknologiarkitekt) Nøglemedarbejdere indenfor it og forretningen Input Eksisterende it-strategidokumenter Output A6.1 It principper, rationale, implikationer. Output kan omfatte: It principper, inddelt i emner for eksempel: applikationer/integrationer, service-orientering, information/data, teknologi, it organisation, og generel tilgang til arkitektur. Gerne med en prioritering. Rationale for de enkelte principper. Implikationer (konsekvens) af principperne Metode Et it-princip fastslår noget fundamentalt om organisationens brug af it for eksempel: "vi udvikler alt selv" (i modsætning til "vi køber kun standard software"). Trinet udarbejder it principper, anfører rationalerne for disse, og analyserer hvilke konsekvenser disse har. En effektiv metode til at nå frem til it-principper der efterleves er: De enkelte aktører kommer med bud på hvilke it principper de mener der er/bør være. De bør være fokuserede på at foreslå principper de mener både i teori og i praksis kan/skal efterleves. Forslagene konsolideres, ved at de grupperes efter emne (som foreslået i output ovenfor), hvorefter dubletter sammenskrives. Gennem workshop at nå igennem med en udvælgelse af eksempelvis top-10 principperne for eksempel gennem afstemning af prioriteter Gode råd Det er vigtigt at holde antallet af principper nede 7-12 eller deromkring. Det er også vigtigt at gøre formuleringen så præcis som mulig, således at reelle beslutninger kan træffes med støtte i principperne. Et udsagn som: vores applikationer skal være brugervenlige er ikke meget værd som princip, da ingen vil argumentere for det modsatte. Et princip som: tværorganisatoriske data skal altid udveksles via XML, og via OIOXML hvis en relevant standard findes stiller derimod et klart krav til design af applikationer. Det er vigtigt at topledelsen er involverede, og støtter principperne. Derfor skal de også formuleres i et sprog der ikke er teknisk, men som alligevel sætter retningslinier som de tekniske arkitekter kan arbejde videre fra Eksempler SKATs arkitekturarbejde er udmøntet i 10 hovedprincipper: OIO EA trinbeskrivelser v1.0 Side 18 af 71 Februar 2007

19 Princip 1: Brugergrænseflader skal være udskiftelige, adskilt fra resten af en IT-løsning, og skal kunne afvikles i flere relevante portaler. Det betyder f.eks., at TastSelvs funktioner kan anvendes af brugere af andre portaler, eksempelvis VIRK.DK, og grafisk kan opdateres uden konsekvenser for den bagvedliggende funktionalitet. Princip 2: Services integreres til processer, forankret i ToldSkats procesmodel, bl.a. via procesmoduler, der kan styre procestrin og informationsudveksling, inkl. roller, ansvar, status og deadlines. Det betyder f.eks., at når virksomheder skal kontrolleres, så sammensættes udsøgningsservices fra Datawarehouse med services fra et sagssystem (ESDH), som danner et brev med henblik på underretning af virksomheder. Princip 3: Brugbare funktioner, som er relevante for forretningen, skal tilgås som services. Services kan uanset teknologi skaleres, genbruges og sammenstilles til nye løsninger. Det betyder f.eks., at servicen "angiv.moms", der kommer fra DR, vil kunne genbruges af andre interne og eksterne IT-løsninger, så unødvendig nyudvikling undgås. Princip 4: Informationer fra grundsystemer udstilles som services - og evt. af ToldSkat Datawarehouse som kopi af hensyn til økonomi, performance eller historik. Det betyder f.eks., at servicen "hent.personoplysninger" fra CSR-P, enkelt vil kunne gen-bruges af flere ITløsninger, hvilket medfører at færre specielforbindelser skal vedligeholdes. Princip 5: Services skal udstilles i ToldSkats og OIOs servicekatalog, forankret i ToldSkats og OIOs begrebsmodel, med servicekvalitet og vilkår for anvendelse. Det betyder f.eks, at ToldSkat har overblik over tilgængelige services og deres servicekvalitet. I OIOs servicekatalog kan eksterne få overblik over de services ToldSkat udstiller eksternt. Princip 6: Løsninger skal kunne rapportere til ToldSkats kvalitetssystem om f.eks. driftsforstyrrelser, servicekvalitet og ressourceforbrug, iht. ITIL mv. Det betyder f.eks., at TastSelv vil rapportere, hvis to ud af ti brugere afvises i forbindelse med selvangivelse. Princip 7: Udviklingsmiljø og dokumentation, bl.a. procesmodel, begrebsmodel, use cases, program-kode og fysisk datamodel, skal via åbne grænseflader være tilgængeligt for ToldSkat og an-dre leverandører. Havde ToldSkat adgang til brugbar arkitekturviden omkring hele systemkomplekset, ville ToldSkat i højere grad kunne sikre, at IT-ydelser blev indkøbt til markedspris. Princip 8: Systemkomplekset skal opdeles i områder der kan drives, vedligeholdes og optimeres uafhængigt af hinanden. Områderne skal defineres ud fra ToldSkats proces- og begrebsmodel. Det betyder f.eks., at ToldSkat, f.eks. vedrørende afregning, vil kunne samle servicen "opret.konto" i et systemområde med én skattekonto. OIO EA trinbeskrivelser v1.0 Side 19 af 71 Februar 2007

20 Princip 9: Løsninger skal genbruge ToldSkats løsningsmodeller og fælles infrastruktur til forskellige behov, bl.a. adgangskontrol og bruger-rollestyring (sikkerhedsmoduler), sagsbehandling (ESDH), kapitalforvaltning, Datawarehouse, samt omlægning af ældre mønstre (TS Tele, delt database, filer mv.). Det betyder f.eks., at ToldSkat ved udvikling af ligningsområdet, vil kunne genbruge standardservices fra ESDH. Princip 10: Arkitekturen afklares iht. ToldSkats projektmodel og arkitekturprincipper, så den understøtter løsningens, ToldSkats og fælles-offentlige forretningsmål, samt relevante OIO-standarder mv., indenfor det økonomiske råderum. Det betyder f.eks., at man inden færdiggørelse af et projektoplæg/-beskrivelse, har haft den krævede sparring, så projektet er optimeret både forretningsmæssigt og arkitektonisk. OIO EA trinbeskrivelser v1.0 Side 20 af 71 Februar 2007

21 4 Aktivitet B: Forretning 4.1 B1. Forretningsobjekter Trinet identificerer de væsentligste forretningsobjekter en it-infrastruktur skal behandle, og angiver evt. hvilke forespørgsler om disse objekter man ønsker foretaget. Trinet opstiller forretningsobjekternes relationer i en struktur Formål Trinet identificerer de væsentligste forretningsobjekter en it-infrastruktur skal behandle, og angiver evt. hvilke forespørgsler om disse objekter man ønsker foretaget. Trinet opstiller forretningsobjekternes relationer i en struktur som en start på udviklingen af en fælles informationsarkitektur for organisationen. Formålet er helt overordnet at sikre at den fremtidige arkitektur centreres omkring de objekter der er centrale for organisationen; at det sikres at it-understøttelsen for disse tænkes ind. Trinet: Identificerer de væsentligste forretningsobjekter en it-infrastruktur skal behandle, og angiver evt. hvilke forespørgsler om disse objekter man ønsker foretaget. Opstiller forretningsobjekternes relationer i en struktur, evt. med attributter og andet, som en start på udviklingen af en fælles informationsarkitektur for organisationen Aktører EA arkitekt Forretningsarkitekt (Informationsarkitekt) Forretningssiden Input Interview/workshop med forretningssiden. Eksisterende begrebsmodeller og logiske datamodeller der måtte foreligge kan indgå som inspiration. Ligeledes kan sektor-begrebsmodeller tjene som grundlag Output Output kan omfatte: B1.1 Forretningsobjekter. Beskrivelse af forretningsobjekter, evt. med de vigtigste attributter og en identifier. B1.2 Forretningsobjekters relationer. Indikation af væsentligste relationer mellem forretningsobjekter. Dette kunne være en logisk datamodel (et entitets-relationsdiagram), men et sådant kan også først blive udviklet i C1. Informationsarkitektur B1.3 Forretningsspørgsmål. Et antal forretningsspørgsmål prioriteret efter hvilken værdi det giver for organisationen at kunne have dem besvaret. Eksempler på forretningsspørgsmål kunne være: hvordan ligger indkomstfordelingen i region X, og hvordan har den ændret sig ; hvordan er aldersfordelingen i denne kommune ; hvor er det billigst at behandle sygdom Y ; osv Metode Et forretningsobjekt (eller blot objekt) repræsenterer en genstand der er vigtig i organisationens dagligdag. Dette kan være fysiske objekter (såsom borger, husdyr, ejendom, osv.) såvel som abstrakte begreber ( patient-henvendelse, tilskud, transaktion, osv.) Man vil normalt have informationer om disse objekter, og behandle dem i informationssystemer. OIO EA trinbeskrivelser v1.0 Side 21 af 71 Februar 2007

22 En forretningsobjektmodel er en begrebsmæssig model der beskriver klasser og relationer mellem de forretningsmæssige informationselementer, som indgår i processerne, udveksles mellem forskellige aktører og deres systemer, og som man har brug for at have informationer om i sit arbejde. Det er derfor vigtigt, at det er forretningssiden der inddrages i at identificere de væsentlige forretningsobjekter. Elementer i metoden omfatter typisk: At lave en kandidatliste af de vigtigste objekter for organisationens arbejde. Dette skal omfatte de objekter der er væsentlige i dag (og som sikkert også er det fremover), men også de objekter der måske ikke behandles i dag, men som organisationen fremover vil skulle behandle. At få disse prioriteret og konsolideret til et overskueligt antal. Dette sker typisk i workshops med forretningssiden. I disse kan man også sætte de vigtigst attributter på de enkelte objekter, så man sikrer en fælles forståelse af hvad de indeholder. Man kan i denne proces også prøve at identificere de vigtigste forretningsspørgsmål som organisationen har brug for at kunne besvare, for at kunne operere effektivt og med høj kvalitet. Disse spørgsmål leder til krav til nuværende og kommende applikationer, og afledt heraf til informations- og applikationsarkitekturen. At strukturere de identificerede objekter. Typisk kan man gruppere dem i en række områder (kunderelaterede objekter, finans-relaterede objekter, etc.) Man vil ofte også opstille dem i et egentlig relationsdiagram, og hertil bruge en E/R-notationsform. Man skal i dette proces-trin ikke tage stilling til hvilke konkrete data format standarder (såsom OIOXML formater) de enkelte objekter eventuelt skal overholde. Dette kommer først i step C1. Informationsarkitektur, og udføres af folk med en lidt mere teknisk tilgangsvinkel Gode råd Der skal typisk ikke være mere end forretningsobjekter. Formålet er at skabe overblik over de væsentligste og deres relationer ikke at lave en detaljeret logisk datamodel (LDM). Et forretningsspørgsmål er ét som det er vigtigt for en bruger at kunne få besvaret for at kunne udføre sit arbejde. Eksempler kunne være: Har denne borger tidligere haft lignende sager med det offentlige? Har patienten tidligere fået konstateret lignende symptomer? Hvilke af ministeriets lejemål udløber inden for et halvt år? Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Tegningen nedenfor identificerer relevante forretningsobjekter for SKAT (i deres terminologi kaldet begreber ), og strukturerer dem i domæne: OIO EA trinbeskrivelser v1.0 Side 22 af 71 Februar 2007

23 Man bemærker at forretningsobjekterne kan være: Konkrete en person, et køretøj og en ejendom afspejler noget fysisk ude i virkeligheden. Abstrakte en personbeskatning eller en afregning er ikke fysisk, men er alligevel begreber (objekter) der indgår i organisationens virke, og skal repræsenteres i et informationssystem. I B1 kan man så småt begynde at arbejde sig hen imod en data model, ved at begynde at opstille relationer mellem objekter. Relationer kan være: Subtyper (generaliseringer/specialiseringer): et objekt er en subtype af et andet. Eks.: en eksportør er en subtype af en virksomhed. Ejerforhold har : et objekt ejer et andet. Eks: Subtype et objekt er en type af et andet. Eks.: Nedenfor er vist et simpelt eksempel på dette: OIO EA trinbeskrivelser v1.0 Side 23 af 71 Februar 2007

24 4.2 B2. Lokationer/organisation Trinet beskriver hvilke lokationer og hvilken organisationsstruktur der findes, og afdækker ansvarsområder for de enkelte enheder Formål Trinet beskriver hvilke lokationer og hvilken organisationsstruktur der findes, og afdækker ansvarsområder for de enkelte enheder. Dette tjener til at identificere hvilke organisationer, lokationer og aktører der skal understøttes med it, indenfor hvilke sammenhænge Aktører EA arkitekt Forretningsarkitekt Forretningssiden Input Interview/workshop med forretningssiden Output Output kan omfatte: B2.1 Lokationsmodel hvilke lokationer (abstrakte, ikke de konkrete fysiske) der findes i organisationen, og som skal understøttes med it. Man kan beskrive lokationernes formål, opgaver, og evt. også antal samt antal af medarbejdere de enkelte lokationer. B2.2 Organisationsmodel en oversigt over hvordan organisationen konkret er struktureret, hvilke eksterne aktører der også bidrager til organisations virke, samt hvilke roller hver af disse varetager. B2.3 Aktørmodel en identifikation af hvilke aktører der findes på de enkelte lokationer og/eller i de enkelte organisationer Metode Som en start kan man indsamle hvad der måtte forefindes af organisationsdiagrammer og rolle-beskrivelser. Derudover er opgaven at abstrahere disse over i logiske lokationer. Dette kan omfatte: kundeservice, lager, finansafdeling, personaleafdeling, indkøb, køretøjer, etc. alt sammen steder der kunne tænkes at have brug for ændret it understøttelse i fremtiden. Man bør dokumentere de organisationer/lokationer/aktører som fremover skal understøttes af nye og modificerede applikationer og services. Dvs. er der organisations/lokalisationsændringer på vej som allerede kendes, bør disse også modelleres ind Gode råd Der er typisk vigtige lokationstyper. Det vigtige er at få identificeret de essentielle, de der påvirker designet af arkitekturen ikke at gå i detaljer med de mindre væsentlige, der nemt kan indpasses i arkitekturen Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Et eksempel på et organisationsdiagram: OIO EA trinbeskrivelser v1.0 Side 24 af 71 Februar 2007

25 Lokation/information mapping: OIO EA trinbeskrivelser v1.0 Side 25 af 71 Februar 2007

26 4.3 B3. Forretningsservices Trinet beskriver hvilke tjenester organisationen leverer, internt og eksternt Formål Trinet beskriver hvilke tjenester organisationen leverer, internt og eksternt. Disse tjenester skal ofte understøttes af it, og måske på en mere hensigtsmæssig måde end i dag, og bør derfor tænkes ind i arkitekturen Aktører EA arkitekt Forretningsarkitekt Forretningssiden Input Interview/workshop med forretningssiden. X1. Forretningsmæssige trends A5. Vision, mål og strategier B1. Forretningsobjekter, B2. Lokationer/organisation, B4. Forretningsprocesser Y5. Kontrakt og aftaleforhold Output Output kan omfatte: B3.1 Forretningsservices. Beskrivelse af forretningsservices, og modtagere af disse. B3.2 Forretningsservices-Lokations map (B2.1-B3.1). Beskrivelse af hvilke lokationer der yder hvilke services. B3.3 Forretningsservices-Organisations map (B2.2-B3.1). Beskrivelse af hvilke organisatoriske enheder der yder hvilke services Metode En forretningsservice er primært vendt mod eksterne modtagere borgere, private virksomheder og andre offentlige organisationer. Man kan dog godt have interne forretningsservices et direktorat der leverer services til f.eks. departementet, eller services rettet mod de enkelte ansatte. Man afdækker, evt. med udgangspunkt i organisations/lokations-diagrammer (B2), hvilke tjenester der leveres hvorfra/fremover skal leveres hvorfra. B5 UseCases kan senere uddybe præcist hvilke aktører i de enkelte organisatoriske enheder/lokationer der gør hvad for at levere de enkelte services. Beskrivelsen bør fokusere på hvilke modtagere der opnår hvilket ved servicen, og ikke på hvordan den i detaljer leveres. De er målet at planlægge it-understøttelsen fremover, så man bør fokusere på de services der fremadrettet skal leveres herunder også nogle der ikke leveres eller kun delvist leveres i dag. Services der udgår, behøver omvendt ikke it-understøttelse fremover. Det er vigtigt at forretningsservices beskrives teknologiuafhængigt. I C4 vil man senere kunne beskrive hvilke (web) services der relaterer til en forretningsservice. Der kan være en 1:1 relation mellem disse, men det behøver ikke at være tilfældet. Under alle omstændigheder er det et mål at man kan udskifte underliggende teknologi uden at forretningsservicen ændres. Man kan med fordel i servicebeskrivelsen inkludere elementer fra en traditionel service level agreement (SLA) såsom svartider, tilgængelighed, etc. Beskrivelsen skal dog være forretningsorienteret altså hvad modtageren af servicen kan forvente (svartider, servicekvalitet, servicevindue) og ikke hvordan (systemoppetider, mv.), Der kan i den forbindelse være nyttigt input at finde i trin Y5 Kontrakt og aftaleforhold. OIO EA trinbeskrivelser v1.0 Side 26 af 71 Februar 2007

27 4.3.6 Gode råd Det er vigtigt at holde service-beskrivelserne på et højt niveau, og at give en god oversigt over de services organisationen som et hele stiller til rådighed, snarere end et meget detaljeret billede. Oversigten kan medtage hvilke forretningsobjekter der benyttes, men der er ikke tale om dataformater, attributter og lignende Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 27 af 71 Februar 2007

28 4.4 B4. Forretningsprocesser Trinet sigter mod at afdække de forretningsprocesser organisationen opererer med, og at identificere de mest kritiske; der hvor it-indsatsen skal fokuseres og om muligt forbedres Formål Trinet sigter mod at afdække de forretningsprocesser organisationen opererer med, og at identificere de mest kritiske; der hvor it-indsatsen skal fokuseres og om muligt forbedres Aktører EA arkitekt Forretningsarkitekt (Applikationsarkitekt) Forretningssiden It-chef Input B1. Forretningsobjekter, B2. Lokationer/organisation, B3. Forretningsservices Interview/workshop med forretningssiden Output En højniveau forretningsmodel for organisationen den hele, eller dele deraf. Output kan omfatte: B4.1 Procesmodel, der beskriver de enkelte processer og aktiviter i disse, og ikke mindst illustrerer flowet af disse. Flowet illustreres typisk grafisk. B4.2 Proces-evaluering: evaluering af forretningsprocessers vigtighed, hold op imod hvor effektivt de understøttes af it, og hvor stor en indsats dette kræves (kritikalitet, effektivitet og udgifter hvor vigtigt er det, hvor godt virker det, og hvad koster det,? ). B4.3 Proces-forretningsobjekt map (B1.1-B4.1), der beskriver: hvilke processer der genererer og bruger hvilke informationer (forretningsobjekter). Man kan også mappe processer imod de informationsobjekter der identificeres i C1, men det kan vise sig at blive meget detaljeret. B4.4 Proces-lokationsmap (B2.1-B4.1), der beskriver hvilke processer der afvikles hvor. B4.5 Proces-organisationsmap (B2.2-B4.1), der beskriver hvilke organisationer der udfører hvilke processer. Som regel er blot en af disse nederste tre mapninger tilstrækkelige Metode Procesmodellen bør udvikles af erfarne proces-modellører. Man vil kunne bruge diverse gængse procesmodelleringsmetoder, f.eks. BPMN eller UML. Det er vigtigt at holde sig på et relativt højt niveau en organisation vil typisk have hovedprocesser og 7-10 supportprocesser. De er målet at planlægge it-understøttelsen for forretningsprocesserne fremover, så man bør fokusere på de processer der fremadrettet skal udføres herunder også nogle der ikke udføres eller kun delvist udføres i dag. Processer der afskaffes behøver omvendt ikke it-understøttelse fremover. Man kan dog modellere både de nuværende (as-is) og de fremtidige (to-be) processer, men så er vi over i retning af business process reengineering, hvilket ikke er fokus med OIO EA. Evalueringen af processerne er vigtig for designet af den fremtidige applikationsarkitektur. Man må søge at få prioriteret processernes vigtighed og den effektivitet brugerne oplever (altså hvor godt supporten for arbejdsopgaverne i de enkelte processer er), sammenholdt med best-in-class. Her er brugerne (forretningssiden) de rigtige at spørge. Samtidig prøver man at få kvantificeret hvor meget it-indsats man samlet set putter ind i de applikationer der understøtter en given proces. Det vil normalt være it-afdelingen der kommer med estimater på it-indsats. OIO EA trinbeskrivelser v1.0 Side 28 af 71 Februar 2007

29 De beskrevne mapninger foretages bedst ved at EA arkitekten laver et oplæg, og reviewer det med it- og forretningssiden. Som nævnt er én af de tre mapninger typisk nok. Nogle gange er det proces-forretningsobjekt der giver mest mening, andre gange proces-lokation/organisation det afhænger lidt af vinklen på EA indsastsen Gode råd Dette er en yderst essentiel aktivitet i et enterprise arkitektur forløb, og bør tjene som referenceramme i en række af de følgende aktiviteter. Man kan kun vanskeligt gå fra forretningsstrategier til applikations- og teknologivalg., uden at sikre at it-understøttelsen af forretningsprocesserne er tænkt ind Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Overordnet SKAT procesmodel: Overordnet SKAT procesmodel - med fokus på eksport: OIO EA trinbeskrivelser v1.0 Side 29 af 71 Februar 2007

30 4.5 B5. Use Cases Dette trin tjener til at forankre det videre arkitektur-arbejde hos brugerne, ved at sikre at de bliver hørt og giver accept til at sådan vil vi gerne arbejde Formål Dette trin tjener til at forankre det videre arkitektur-arbejde hos brugerne, ved at sikre at de bliver hørt og giver accept til at sådan vil vi gerne arbejde Aktører EA arkitekt Forretningsarkitekt Applikationsarkitekt Forretningssiden, brugerne Input B2. Lokationer/organisation. B3. Forretningsservices, B4. Forretningsprocesser Interview/workshop med forretningssiden, herunder ikke mindst de der dagligt udfører de relevante arbejdsopgaver Output Output er: B5.1 Use Cases. Disse beskriver hvilke opgaver som aktører mennesker og systemer i samspil skal kunne løse. Use Casene beskriver hvad der løses - ikke i nogen videre detalje hvordan dette foregår. En Use Case består typisk af en beskrivelse af: Aktører hvem løser opgaven? Både mennesker og systemer kan være aktører. Præ-konditioner i hvilken situation er det at opgaven skal løses, og hvad foreligger der at tage udgangspunkt i? Denne del kan også beskrive triggers, altså hændelser eller udlæsende begivenheder der gør at Use Casen bliver aktuel at få udført. Post-konditioner hvad skal være sket når opgaven er løst? Forretningsregler hvilke betingelser skal være opfyldt både før og efter udførelsen af opgaven? Selve Use Case-beskrivelserne; hvad skal udføres? (men i mindre grad: hvordan) Alternative Use Cases disse supplerer de normale Use Cases ved at beskrive hvad der sker hvis noget går galt. Tilføjelser, kommentarer og så videre, der kan hjælpe de der skal sørge for at Use Cases implementeres. Use Case teknikken hidrører fra UML metoden, og UML Use Case notationsformen anvendes ofte her Metode Metoden består typisk i at de ansvarlige arkitekter først laver udkast til de enkelte Use Cases, og så gennem grundige workshops sikre at brugerne forstår Use Casene, får afleveret deres input til disse; hvordan de ser deres fremtidige arbejdssituation. Det er vigtigt at få opsamlet alle de ideer og forlag der fremkommer, og få disse dokumenteret, således at brugerne kan se hvordan disse imødekommes i det videre forløb, hvor arkitekturen konkretiserer ønskerne i løsningsdesigns til applikationer og infrastruktur. Det er vigtigt at Use Casene afspejler et ønsket forløb, og at man ikke blot dokumenterer hvad man kan i dag. Man skal overveje detailniveauet i Use Casene det kan spænde fra meget overordnet til så detaljeret at man nærmest kan designe et system efter det. Man kan med fordel oprette højniveau Use Cases, og så nedbrude de kritiske af dem, ved at tilføje sub-usecases. Use Cases og workflows er en dialogmekanisme, hvor aktørerne udtrykker sig i brugertermer, der så oversættes til teknologikrav ikke mindst til applikationsarkitekturen. Dette stiller store krav til den OIO EA trinbeskrivelser v1.0 Side 30 af 71 Februar 2007

31 faciliterende Enterprise Arkitekt, at vedkommende skal kunne forstå begge verdener. Udviklingen af navnlig workflows vil ofte foregå i parallel med applikations- og informations-arkitektur designet. Use Cases er ofte et nyttigt værktøj til kravstyring. Man kan med fordel holde Use Casene op imod den fremtidige løsning som arkitekturen foreslår, (specielt applikationsarkitekturen i C2), for at sikre at brugernes ønsker rent faktisk mødes Gode råd Det er essentielt, at de arkitekter der faciliterer opgaven, er i stand til at sætte sig i brugernes sted, og ikke tænke i teknologi, men i behov. Som ansvarlig for en Use Case leverance bør man kun til en vis grad bruge sin teknologiske viden til at komme med forslag, men derimod i høj grad lytte til brugernes behov og ideer. Man kan med fordel navngive Use Cases så de intuitivt og i aktivt sprog udsiger hvad Use Cases forårsager: registrer borger, arkiver sag, osv Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Use Case oversigt: OIO EA trinbeskrivelser v1.0 Side 31 af 71 Februar 2007

32 OIO EA trinbeskrivelser v1.0 Side 32 af 71 Februar 2007

33 Beskrivelse af enkelt Use Case: OIO EA trinbeskrivelser v1.0 Side 33 af 71 Februar 2007

34 4.6 B6. Workflow Dette trin 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 Formål Dette trin 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. Dette tjener ikke mindst til at sikre at arbejdsdelingen mellem forskellige aktører (organisatoriske enheder) afdækkes og forankres. Dette kan også medføre ønsker der føder ind i designet af systemunderstøttelsen af arbejdsgangene Aktører (EA arkitekt) Forretningsarkitekt (Applikationsarkitekt) Forretningssiden, brugere Input A5. Vision, mål og strategier, A6. It-principper. B2. Lokationer/organisation. B3. Forretningsservices, B4. Forretningsprocesser, B5. Use Cases Eksisterende workflow beskrivelser Output Output kan omfatte: B6.1 Workflows. Disse kan dokumenteres i klassik svømmebane diagrammeringsstil, der beskriver aktiviteters flow og hvilke aktører (organisatoriske enheder) der foretager hvad, hvornår. Forretningsregler tilknyttede workflows. Disse kan tage udgangspunkt i mere overordnede forretningsregler fra A5.4 Forretningsregler, og relaterer disse til konkrete workflows, idet de beskriver eksempelvis: o Tidsmæssige sammenhænge (for eksempel at denne delopgave skal være afsluttet senest 2 døgn før svaret udsendes, så der er tid til at reviewe besvarelsen. o Systemmæssige sammenhænge ( denne godkendelse foretages altid i system X ) o Organisatoriske sammenhænge ( enhed Y skal altid orienteres om at arbejdsgangen nu er nået hertil, og at der afventes et svar ) Metode Workflows er en detaljering af UseCases, hvor man mere detaljeret viser hvordan opgaverne løses, og af hvem. Bemærk: Workflowene skal primært være de fremtidige hvordan brugerne forestiller sig at arbejde med de nye systemer. Der kan være faser af workflows, svarende til faser i implementeringen af den fremtidige arkitektur. Man kan dog godt forestille sig at man tegner de nuværende workflows op først, som en hjælp til at designe de fremtidige. Der er ikke en en-til-en sammenhæng mellem et workflow og en UseCase. Et workflow kan (helt eller delvist) beskrive flere UseCases, og en UseCase kan være beskrevet i flere workflows. Workflows og forretningsregler udarbejdes bedst i sammenhæng sådan at forretningsregler der er bred enighed om, kommer til at diktere hvordan nogle workflows kommer til at forme sig, og at de naturlige workflows der fremkommer, kommer til at introducere nye forretningsregler. Som i Use Case arbejdet er det en god ide at følge en fremgangsmåde som nedenstående: Den ansvarlige arkitekt lister (typisk med udgangspunkt i UseCases) de workflows han/hun mener skal beskrives, og laver et første udkast til disse, samt til tilhørende forretningsregler. OIO EA trinbeskrivelser v1.0 Side 34 af 71 Februar 2007

35 De skitserede workflows/forretningsregler reviewes enkeltvis med de aktører der indgår. Efter 1:1 reviewrunden må arkitekten søge at tilpasse workflowene/forretningsreglerne så de kan dække aktørernes ønsker bedst muligt. Dette er ikke altid muligt nye systemer betyder ofte nye arbejdsgange, hvor ansvar for opgaver ændres. De modificerede workflows/forretningsregler sendes ud til aktørerne, og der afholdes en workshop med alle aktører samlet, hvor nogle de uoverensstemmelser der er bringes op og søges løst. Dette enten ved at arbejdsgangen ændres, eller ved at den underliggende systemunderstøttelse modificeres. Fokus i et workflow er ikke mindst de steder hvor kontrol skifter fra én aktør til en anden. Dette vil typisk medføre krav til en integration imellem applikationer, eller til en funktionalitet i en applikation (herunder også sikkerhedskrav). Det er dog vigtig at være opmærksom på at en kontrol-overgang ikke nødvendigvis er systemunderstøttet men man kan stadig betragte de aftaler der indgås i workflowene som en del af en enterprise arkitektur. UseCases og workflows er en dialogmekanisme, hvor aktørerne udtrykker sig i brugertermer, der så oversættes til teknologikrav ikke mindst til applikationsarkitekturen. Dette stiller store krav til den faciliterende arkitekt, at vedkommende skal kunne forstå begge verdener. Udviklingen af navnlig workflows vil ofte foregå i parallel med applikations- og informations-arkitektur designet. Som diagrammeringsteknik vil svømmebaner ofte være en god ide. Man kan benytte sig af UML aktivity diagram, UML state diagram, BPMN (Business Process Modelling Notation), eller andre gængse workflow diagrammeringsformer Gode råd Det er essentielt, at de arkitekter der faciliterer opgaven, er i stand til at sætte sig i brugernes sted, og ikke tænke i teknologi, men i behov. Som ansvarlig for en Use Case leverance bør man kun til en vis grad bruge sin teknologiske viden til at komme med arbejdsgange-forslag, men derimod i høj grad lytte til brugernes behov og ideer. Workflows er både anvendelige internt, og som materiale i en kravspecifikation Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Workflow på højt niveau. Følgende figur identificerer et workflow (kunne også kaldes en aktivitet): OIO EA trinbeskrivelser v1.0 Side 35 af 71 Februar 2007

36 Workflow på et detaljeret niveau: Et andet eksempel på et detaljeret workflow: OIO EA trinbeskrivelser v1.0 Side 36 af 71 Februar 2007

37 5 Aktivitet C: Teknologi 5.1 C1. Informationsarkitektur Trinet beskriver den nuværende og den fremtidige informationsarkitektur. Herunder udvikles en logisk datamodel og et data distibutionsskema Formål Trinet beskriver den nuværende og den fremtidige informationsarkitektur. Trinet uddyber forretningsobjekterne fra B1 til en egentlig logisk datamodel, der tjener som grundlag for at konsolidere organisationens informationer. Trinet giver samtidig en arkitektur for hvordan disse informationer skal struktureres fremover hvilke databaser der skal eksistere hvor, osv Aktører EA arkitekt Informationsarkitekt Organisationens database-ansvarlige Organisationens begrebs/informationsmodellerings-ansvarlige It-chef Input Til nuværende informationsarkitektur: Eksisterende dokumentation Interview med it nøglepersoner. Til fremtidig informationsarkitektur: Nuværende arkitekturer indgår. Specielt C1. Informationsarkitektur (nuværende) skal være dokumenteret for at man meningsfyldt kan definere en fremtidig informationsarkitektur og senere en migreringsplan fra nuværende til fremtidig (trin E2). B1. Forretningsobjekter er et centralt input, uden B1 vil det være vanskeligt at udvikle en forretningsorienteret informationsarkitektur. A6. It-principper, B2. Lokationer/organisation, B3. Forretningsservices, B4. Forretningsprocesser, B5. UseCases og B6. Workflow kan tjene til at støtte udformningen af C1. C2. Applikationsarkitektur, C3. Servicearkitektur og C4. Teknologiarkitektur kan give inspiration i det omfang de findes men ofte starter man med C1 og har ikke de øvrige på plads. Interview/workshop med forretningssiden. Eksisterende logiske datamodeller og evt. essentielle data-beskrivelser der måtte foreligge (i skemaer, på skærmbilleder osv.) kan indgå som inspiration Output Dette trin producerer to sæt OIO EA-produkter: ét der beskriver den nuværende informationsarkitektur, og et der beskriver den fremtidige informationsarkitektur ( as-is og to-be ). For både den nuværende og fremtidige arkitektur kan OIO EA output produkterne omfatte: C1.1 Informationsobjekter i LDM. Her sker en uddybning af forretningsobjekt modellen (B1) til noget der ligner (er) en logisk datamodel (LDM). Her beskrives attributter for de enkelte objekter, deres indbyrdes relationer og kardinaliteter. C1.2 Data distribution for de enkelte logiske objekter: en oversigt (gerne i et lokationsdiagram) over hvilke datastrømme der er hvordan horisontale og vertikale fragmenter af data flyder rundt i organisationen. I relation til SOA: Et SOA princip er at en services data kun kan tilgås via servicen og ikke direkte i databasen. Derfor må replikering og opdateringsansvar analyseres (f.eks. bør data kun opdateres et sted for at undgå inkonsistens). OIO EA trinbeskrivelser v1.0 Side 37 af 71 Februar 2007

38 C1.3 Database-oversigt. Dette er en oversigt over nuværende og fremtidige databaser indhold, størrelse, teknologi-platform, kvalitet af data, etc. C1.4 Fysisk datamodel, inkl. OIOXML. Her bliver man meget konkret med valg af datastandarder for de enkelte logiske objekter. Ikke mindst bør man specificere hvilke OIO datastandarder der skal overholdes herunder referere de helt konkrete OIOXML skemaer der allerede findes, og specificere hvilke nye der bør udvikles Metode Nuværende arkitektur: at afdække den nuværende arkitektur er i høj grad et arkæologi-arbejde. En EA arkitekt kan med fordel udvikle skabeloner til de dele af den nuværende arkitektur man vil afdække (jfr. Outputleverancerne). Disse udfyldes så af de af organisationens it-personer der har ansvar for de enkelte områder, ofte bistået af en leverandør. Det er vigtigt at bemærke følgende: Der er fire arkitekturområder: informations-, applikations-, service- og teknologiarkitektur, og dermed fire nuværende og fire fremtidige arkitekturer. Man dokumenterer dog ikke nødvendigvis alle, det er en del af tilpasningen af OIO EA metoden (trin A3) at definere hvilke der dokumenteres. Generelt: - Hvis man designer den fremtidige arkitektur indenfor et af de fire område, skal man dokumentere den nuværende indenfor dette område. - Hvis ikke man designer den fremtidige arkitektur indenfor et område, vil man ofte kunne spare at dokumentere den nuværende indenfor dette område, eller kun dokumentere den ret kortfattet. Dokumentation af nuværende arkitektur kræver ikke meget erfarne arkitekter udover en senior enterprise arkitekt til at skabe dokumentationsrammen og at overvåge og guide arbejdet, kan hovedparten af dataindsamlingen foretages af folk med noget mindre erfaring. Man kan med fordel dokumentere de nuværende arkitekturer i parallel. Ligeledes kan man indenfor en nuværende arkitektur definere de valgte output i parallel (én/flere dokumenterer applikationer, én dokumenterer integrationer, etc.) Høj grad af parallelitet fremmer at man hurtigere har grundlaget for at gå videre til designet af de fremtidige arkitekturer. EA arkitektens rolle i dokumentationen af den nuværende arkitektur er i høj grad at sikre konsistens og komplethed på tværs af områderne, og at rådgive om den ønskelige grad af detaljering der er krævet, for at sikre et godt fundament for den fremtidige arkitektur. De fleste organisationer har beskrevet dele af deres nuværende arkitektur, men i varierende grad af detaljering, komplethed og konsistens. Samtidig har mange organisationer svært ved at holde informationerne opdaterede. Der ligger en stor opgave for EA arkitekten i at sikre den indsamlede informations kvalitet, korrekthed og komplethed. Herudover har EA arkitekten opgaven med at sikre at organisationens medarbejde hjælper med at indsamle den information der indgår i dokumentationen af den nuværende. Dette er dog normalt ikke så vanskeligt, da området jo ikke er videre kontroversielt. Det kan være en relativt stor opgave at få dokumenteret den nuværende arkitektur. Til gengæld har en sådan oversigt en stor værdi, ikke blot for et EA projekt, men også for de teknologiprojekter der pågår i organisationen. Det er derfor en god ide allerede ved arbejdets begyndelse at have en plan for hvordan informationen vedligeholdes af hvem, under brug af hvilke værktøjer, hvordan vedligeholdelsespligten forankres, etc. En del af dette hører under Y3. EA governance. Fremtidige arkitektur: Hvor kortlægning af den nuværende arkitektur er en dokumentationsopgave, er udvikling af den fremtidige en designopgave. Denne kræver en hel anden grad af detaljeret fagdybde, og involverer en lang række specialister indenfor de enkelte arkitektur-områder, der hver især behersker metoder og teknikker indenfor området. Samtidig er området ofte meget følsomt, der kan være forskellige fløje i organisationen der advokerer forskellige teknologier. I LDM-arbejdet har man brug for klassiske datamodellerings-kompetencer. Fokus bør være på at etablere en ønskelig fremtidig informationsstruktur, der bedre understøtter forretnings-processerne. Temaer kan typisk være: "konsolidering af 'kunde' information (patient, borger)", "al data ét sted", og "historik tilgængelig". Det er dog ikke givet at al data for et givent logisk objekt for eksempel altid kan samles kun ét sted; man vil i al fald ofte se at dette kræver en migrering, og på det fysiske niveau noget data vask/data transformation. Man kan i dette EA trin også tage stilling til hvilke konkrete data format standarder (såsom OIOXML formater) de enkelte objekter eventuelt skal overholde. Er der ikke nogle relevante OIOXML standarder, kan dette give anledning til at det overvejes at definere disse. OIO EA trinbeskrivelser v1.0 Side 38 af 71 Februar 2007

39 I data distribution søger man at kortlægge hvilke datastrømme der naturligt flyder, så man kan designe sin database struktur efter dette. Ideelt set kunne man måske lægge al data centralt, men der vil ofte være en række grunde til at have decentrale, horisontale og vertikale udsnit af data: sikkerhed, performance, teknologiske hindringer, etc. På baggrund af data distributionsskemaet kan man begynde at designe hvilke mængder data der skal flyttes rundt, med hvilke realtime-krav, sikkerhedskrav, etc. Herudfra kan man begynde at placere de enkelte databaser per lokation. Man har samtidig input til valg af konkret database management system teknologier. Et datadistributionsskema er naturligvis mest relevant for større organisationer med flere fysiske lokationer. En praktisk måde at konsolidere data på er at etablere et datavarehus, hvor al relevant data samles og gøres tilgængelig via rapportudtræk og business intelligence værktøjer Gode råd Nuværende arkitektur: Det giver værdi at have mange bidragsydere til at dokumentere denne, og komme relativt hurtigt i mål med oversigten over den nuværende arkitektur. Man bør også bestemme sig for hvem af de deltagende der fortsætter med at udarbejde den fremtidige arkitektur. Det bemærkes, at projekter der pågår også skal regnes ind under den nuværende EA. Fremtidig arkitektur: Der vil typisk være omkring logiske informationsobjekter. Formålet er at lave en Logisk Data Model (LDM), dog ikke i detaljer. Et senere skridt vil være at ombryde denne til en fysisk datamodel, hvor relationer normaliseres, hvor der tænkes på implementerings-effektivitet, og hvor mindre vigtige informationsobjekter identificeres og defineres. I enterprise arkitektur-arbejdet er det essentielt at få et godt overblik over de allermest mest essentielle informationsobjekter og relationer mellem disse. En stor organisation vil ofte have informationsobjekter (forretningsbegreber), og det er derfor vigtigt i en enterprise arkitektur at identificere de væsentligste objekter og designe de væsentligste relationer. Projekter som følge af migreringsplanen vil altid kunne uddybe og tilføje objekter og attributter, så fokus i dette trin er af definere en velgennemtænkt grundstruktur. Det er også vigtigt at læne sig op af at eksisterende dataformat-standarder. Sektorstandardisering er i vækst, og producerer de relevante OIO datastandarder (OIOXML) man bør benytte Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Informationsarkitektur 1: OIO EA trinbeskrivelser v1.0 Side 39 af 71 Februar 2007

40 Informationsarkitektur 2: OIO EA trinbeskrivelser v1.0 Side 40 af 71 Februar 2007

41 5.2 C2. Applikationsarkitektur Trinet beskriver den nuværende og den fremtidige applikationsarkitektur. Dette omfatter at optegne applikations- og integrationslandskaberne Formål Trinet beskriver den nuværende og den fremtidige applikationsarkitektur. Trinet definerer hvilke applikationer og integrationer der nu understøtter, og fremover skal understøtte organisationens arbejdsgange. Herved skabes fundamentet for at planlægge nødvendige udfasninger af eksisterende applikationer, og implementering/integration af de nye, der bedre opfylder organisationens behov Aktører EA arkitekt Applikationsarkitekt Organisationens applikationsudviklere Input Til nuværende applikationsarkitektur: Eksisterende dokumentation Interview med it nøglepersoner. Til fremtidig applikationsarkitektur: Nuværende arkitekturer indgår. Specielt C2. Applikationsarkitektur (nuværende) skal være dokumenteret for at man meningsfyldt kan definere en fremtidig applikationsarkitektur og senere en migreringsplan fra nuværende til fremtidig (trin E2). B4. Forretningsprocesser, B3. Forretningsservices og B1. Forretningsobjekter er meget centrale som input til dette trin. A6. It-principper, B2. Lokationer/organisation, B5. Use Cases og B6. Workflow giver god input til trinet. C1. Informationsarkitektur og C3. Servicearkitektur, og C4. Teknologiarkitektur giver ligeledes god støtte, i det omfang de findes. Specielt C4 vil ofte først foreligge senere, men kan give anledning til modifikation af navnlig C2-C Output Dette trin producerer to sæt OIO EA-produkter: ét der beskriver den nuværende informationsarkitektur, og et der beskriver den fremtidige informationsarkitektur ( as-is og to-be ). For både den nuværende og fremtidige arkitektur kan OIO EA output produkterne omfatte: C2.1 Applikationskatalog, der giver en oversigt over funktionalitet, teknologi-platform, brugere, integrationer, mv. for de enkelte applikationer. C2.2 Applikation-Information map (C1.1-C2.1), der beskriver hvilke applikationer der bruger hvilke informationsobjekter fra C1 gerne i en matrix, og gerne med angivelse af hvorvidt applikationen opretter, læser, skriver eller sletter informationen). C2.3 Applikation infrastruktur mønstre, der beskriver hvordan den enkelte applikations data-, funktions- og præsentationskomponenter fordeler sig. C2.4 Applikation-Proces map (B4.1-C2.1), hvor man prøver at få et overblik over hvilke applikationer der understøtter hvilke forretningsprocesser (fra B4), og eventuelt også hvor god denne understøttelse er. C2.5 Integrationskatalog, der giver en oversigt over funktionalitet, teknologi-platform, data flow, mv. for de enkelte integrationer. C2.6 Integrationsstrategi og integration patterns beskriver tilgangen til integrationer. Dette omfatter den generelle strategi (for eksempel brug af integrationsbus) samt de konkrete patterns (mønstre) man har valgt til integrationerne (publish-subscribe, request-provide, etc.). C2.7 Applikation-Integration views (C2.1-C2.5-C1.1 kombineret) beskriver applikationers integrationer, typisk som diagrammer med pile der viser data flow mellem applikationerne. Disse views OIO EA trinbeskrivelser v1.0 Side 41 af 71 Februar 2007

42 kan med fordel gøres domænespecifikke, så der er ét per funktionelt område. Bemærk at et domæneview vil ofte være lig med et system (hvor et system er en samling applikationer der tilsammen hjælper brugerne med at løse sæt sammenhængende opgaver sagsbehandling, personaleadministration, etc) Metode Nuværende arkitektur: at afdække den nuværende arkitektur er i høj grad et arkæologi-arbejde. En EA arkitekt kan med fordel udvikle skabeloner til de dele af den nuværende arkitektur man vil afdække (jfr. Outputleverancerne). Disse udfyldes så af de af organisationens it-personer der har ansvar for de enkelte områder, ofte bistået af en leverandør. Det er vigtigt at bemærke følgende: Der er fire arkitekturområder: informations-, applikations-, service- og teknologiarkitektur, og dermed fire nuværende og fire fremtidige arkitekturer. Man dokumenterer dog ikke nødvendigvis alle, det er en del af tilpasningen af OIO EA metoden (trin A3) at definere hvilke der dokumenteres. Generelt: - Hvis man designer den fremtidige arkitektur indenfor et af de fire område, skal man dokumentere den nuværende indenfor dette område. - Hvis ikke man designer den fremtidige arkitektur indenfor et område, vil man ofte kunne spare at dokumentere den nuværende indenfor dette område, eller kun dokumentere den ret kortfattet. Dokumentation af nuværende arkitektur kræver ikke meget erfarne arkitekter udover en senior enterprise arkitekt til at skabe dokumentationsrammen og at overvåge og guide arbejdet, kan hovedparten af dataindsamlingen foretages af folk med noget mindre erfaring. Man kan med fordel dokumentere de nuværende arkitekturer i parallel. Ligeledes kan man indenfor en nuværende arkitektur definere de valgte output i parallel (én/flere dokumenterer applikationer, én dokumenterer integrationer, etc.) Høj grad af parallelitet fremmer at man hurtigere har grundlaget for at gå videre til designet af de fremtidige arkitekturer. EA arkitektens rolle i dokumentationen af den nuværende arkitektur er i høj grad at sikre konsistens og komplethed på tværs af områderne, og at rådgive om den ønskelige grad af detaljering der er krævet, for at sikre et godt fundament for den fremtidige arkitektur. De fleste organisationer har beskrevet dele af deres nuværende arkitektur, men i varierende grad af detaljering, komplethed og konsistens. Samtidig har mange organisationer svært ved at holde informationerne opdaterede. Der ligger en stor opgave for EA arkitekten i at sikre den indsamlede informations kvalitet, korrekthed og komplethed. Herudover har EA arkitekten opgaven med at sikre at organisationens medarbejde hjælper med at indsamle den information der indgår i dokumentationen af den nuværende. Dette er dog normalt ikke så vanskeligt, da området jo ikke er videre kontroversielt. Det kan være en relativt stor opgave at få dokumenteret den nuværende arkitektur. Til gengæld har en sådan oversigt en stor værdi, ikke blot for et EA projekt, men også for de teknologiprojekter der pågår i organisationen. Det er derfor en god ide allerede ved arbejdets begyndelse at have en plan for hvordan informationen vedligeholdes af hvem, under brug af hvilke værktøjer, hvordan vedligeholdelsespligten forankres, etc. En del af dette hører under Y3. EA governance. Fremtidige arkitektur: Hvor kortlægning af den nuværende arkitektur er en dokumentationsopgave, er udvikling af den fremtidige en designopgave. Denne kræver en hel anden grad af detaljeret fagdybde, og involverer en lang række specialister indenfor de enkelte arkitektur-områder, der hver især behersker metoder og teknikker indenfor området. Samtidig er området ofte meget følsomt, der kan være forskellige fløje i organisationen der advokerer forskellige teknologier. Formålet er at give et overblik over applikationslandskabet, og for de enkelte applikationer at beskrive deres funktioner, tekniske platform. Samtidig skal integrationerne imellem applikationerne identificeres, og de enkelte integrationers tekniske platform beskrives. Fra B4 Forretningsprocesser har vi en indikation af de enkelte processers vigtighed, hvor meget it understøttelse man giver dem, og hvor godt det virker. Ved at mappe applikationer til processer får man nu et endnu bedre udgangspunkt for at vurdere hvilke applikationer der bør modificeres eller udskiftes. Der kan være flere grunde til at modificere eller udskifte applikationer, herunder: Der er nye forretningsbehov der kræver ændret it-understøttelse. OIO EA trinbeskrivelser v1.0 Side 42 af 71 Februar 2007

43 Standard-software pakker findes til erstatning for egenudviklede applikationer. Nogle applikationer kører på forældede platforme der ikke længere kan opgraderes. Fusioner, organisationsændringer og andet kræver applikationskonsolidering. Ændrede love og markedsvilkår kræver nye rapporteringsformer og nye tjenester, som skal implementeres af nye applikationer. Ved at optegne de nye applikationer og også fra data distribution/data flow diagrammerne i C1 får man en god ide om integrationsstrukturen. Herefter må man med udgangspunkt i kravene til den enkelte integration mht. datamængder, hyppighed, krav til sikkerhed, osv. vælge den integrationsteknologi der giver bedst mening. Man kan overveje om man helt generelt ønsker at implementere en integrationsplatform, der reducerer antallet af integrationer og forhindrer N:N integrationer. En integrationsstrategi kunne eksempelvis være publishsubscribe, hvor en applikation der håndterer en forretningsbegivenhed (såsom at en patient er blevet indlagt, en borger har ansøgt om et eller andet) publicerer denne forretningsbegivenhed på en generel integrationsplatform. Andre applikationer der tager sig af denne type begivenheder, kan så abonnere på begivenheden. Endelig bør man i arkitekturen tage højde for krav til interoperabilitet mange applikationer passer i dag ikke ind i en integrationsplatform, og har i stedet behov for en løsere kobling til protokoller og dataformater. Det er hensigtsmæssigt at applikationsarkitekturen tager højde for at der i fremtiden (uvægerligt) vil komme nye protokoller og formater, som smidigt kan adopteres uden gennemgribende af kernen af applikationen Gode råd Nuværende arkitektur: Det giver værdi at have mange bidragsydere til at dokumentere denne, og komme relativt hurtigt i mål med oversigten over den nuværende arkitektur. Man bør også bestemme sig for hvem af de deltagende der fortsætter med at udarbejde den fremtidige arkitektur. Det bemærkes, at projekter der pågår også skal regnes ind under den nuværende EA. Fremtidig arkitektur (og nuværende): Bliv enig om terminologien omkring applikation og system hvad er hvad? Ofte vil man bruge termen system om et kompleks af applikationer indenfor et sammenhængende område (for eksempel en håndfuld applikationer der tilsammen håndterer tilskudsadministration og samlet benævnes tilskudsadministrationssystemet ) Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 43 af 71 Februar 2007

44 5.3 C3. Servicearkitektur Trinet beskriver den nuværende og den fremtidige servicearkitektur Formål Trinet beskriver den nuværende og den fremtidige servicearkitektur. Trinet tjener til formål at øge genbrugelighed; dels ved at konsolidere fælles services der, og dels ved at lade applikationer publicere deres services til omverdenen. Et mål er også at gøre applikationsporteføljen mere fleksibel (agilitet at man nemt kan reagere på skiftende behov) Aktører EA arkitekt Informationsarkitekt Applikationsarkitekt Applikationsudviklere Input Til nuværende servicearkitektur: Eksisterende dokumentation. Interview med it nøglepersoner. Til fremtidig servicearkitektur: Nuværende arkitekturer indgår. Specielt C3. Servicearkitektur (nuværende) bør være dokumenteret for at man meningsfyldt kan definere en fremtidig servicearkitektur og senere en migreringsplan fra nuværende til fremtidig (trin E2). A6. It-principper B3. Forretningsservices, (B4. Forretningsprocesser) C1. Informationsarkitektur, C2. Applikationsarkitektur og C4. Teknologiarkitektur, i det omfang de foreligger. Specielt C4 vil ofte først foreligge senere, men kan give anledning til modifikation af navnlig C2-C Output Dette trin producerer to sæt OIO EA-produkter: ét der beskriver den nuværende informationsarkitektur, og et der beskriver den fremtidige informationsarkitektur ( as-is og to-be ). For både den nuværende og fremtidige arkitektur kan OIO EA output produkterne omfatte: C3.1 Serviceoversigt, der giver en oversigt over hvilke services der udbydes for nuværende, og skal udbydes fremover (typisk som webservices). Denne kan med fordel have to dele: o - En teknologi-uafhængig del, hvor servicen beskrives ud fra hvad den gør. Dette kan også omfatte teknologi-uafhængige dele af en SLA (service level agreement). o - En teknologi-afhængig del, hvor der findes detaljer om hvordan servicen er/bør blive implementeret. Dette kan omfatte integrationsmønstre, samt de teknologi-afhængige dele af en SLA (service level agreement). C3.2 Komponentopdelt applikationslandskab, hvor services der er implementeret flere steder, er trukket ud og planlagt så de kun implementeres ét sted. Igen kan der være en nuværende komponentopdeling, og en planlagt fremtidig. Komponentopdeling svarer i virkeligheden til kerneservices på samme måde som kernekomponenter i OIOXML verdenen dvs. de services/komponenter der er mest centrale og genbrugelige. Dette landskab viser altså hvordan de services der er identificeret i serviceoversigten bruges, og kan samtidig hjælpe til at identificere nye komponenter der kan gøres til services. C3.3 (Web)service-forretningsservice map (B3.1-C3.1), der er en mapning af de ovenfor identificerede (web)services (nuværende og fremtidige) ind i de forretningsservices som B3 identificer. Herved får man beskrevet hvordan de forretningsmæssige services realiseres af tekniske services, og dermed et værktøj til at styre hvordan man ændrer de forretningsmæssige services og hvilke forretningsmæssige services der kan påvirkes af at skifte teknisk service-leverandør. OIO EA trinbeskrivelser v1.0 Side 44 af 71 Februar 2007

45 5.3.5 Metode Nuværende arkitektur: at afdække den nuværende arkitektur er i høj grad et arkæologi-arbejde. En EA arkitekt kan med fordel udvikle skabeloner til de dele af den nuværende arkitektur man vil afdække (jfr. Outputleverancerne). Disse udfyldes så af de af organisationens it-personer der har ansvar for de enkelte områder, ofte bistået af en leverandør. Det er vigtigt at bemærke følgende: Der er fire arkitekturområder: informations-, applikations-, service- og teknologiarkitektur, og dermed fire nuværende og fire fremtidige arkitekturer. Man dokumenterer dog ikke nødvendigvis alle, det er en del af tilpasningen af OIO EA metoden (trin A3) at definere hvilke der dokumenteres. Generelt: - Hvis man designer den fremtidige arkitektur indenfor et af de fire område, skal man dokumentere den nuværende indenfor dette område. - Hvis ikke man designer den fremtidige arkitektur indenfor et område, vil man ofte kunne spare at dokumentere den nuværende indenfor dette område, eller kun dokumentere den ret kortfattet. Dokumentation af nuværende arkitektur kræver ikke meget erfarne arkitekter udover en senior enterprise arkitekt til at skabe dokumentationsrammen og at overvåge og guide arbejdet, kan hovedparten af dataindsamlingen foretages af folk med noget mindre erfaring. Man kan med fordel dokumentere de nuværende arkitekturer i parallel. Ligeledes kan man indenfor en nuværende arkitektur definere de valgte output i parallel (én/flere dokumenterer applikationer, én dokumenterer integrationer, etc.). Høj grad af parallelitet fremmer at man hurtigere har grundlaget for at gå videre til designet af de fremtidige arkitekturer. EA arkitektens rolle i dokumentationen af den nuværende arkitektur er i høj grad at sikre konsistens og komplethed på tværs af områderne, og at rådgive om den ønskelige grad af detaljering der er krævet, for at sikre et godt fundament for den fremtidige arkitektur. De fleste organisationer har beskrevet dele af deres nuværende arkitektur, men i varierende grad af detaljering, komplethed og konsistens. Samtidig har mange organisationer svært ved at holde informationerne opdaterede. Der ligger en stor opgave for EA arkitekten i at sikre den indsamlede informations kvalitet, korrekthed og komplethed. Herudover har EA arkitekten opgaven med at sikre at organisationens medarbejde hjælper med at indsamle den information der indgår i dokumentationen af den nuværende. Dette er dog normalt ikke så vanskeligt, da området jo ikke er videre kontroversielt. Det kan være en relativt stor opgave at få dokumenteret den nuværende arkitektur. Til gengæld har en sådan oversigt en stor værdi, ikke blot for et EA projekt, men også for de teknologiprojekter der pågår i organisationen. Det er derfor en god ide allerede ved arbejdets begyndelse at have en plan for hvordan informationen vedligeholdes af hvem, under brug af hvilke værktøjer, hvordan vedligeholdelsespligten forankres, etc. En del af dette hører under Y3. EA governance. Fremtidig arkitektur: Hvor kortlægning af den nuværende arkitektur er en dokumentationsopgave, er udvikling af den fremtidige en designopgave. Denne kræver en hel anden grad af detaljeret fagdybde, og involverer en lang række specialister indenfor de enkelte arkitektur-områder, der hver især behersker metoder og teknikker indenfor området. Samtidig er området ofte meget følsomt, der kan være forskellige fløje i organisationen der advokerer forskellige teknologier. Det er målet at "serviceorientere" de dele af arkitekturen det er hensigtsmæssigt at serviceorientere (SOA). Med udgangspunkt i den applikationsstruktur der er beskrevet i C2, går man nu så at sige ind i maven på de enkelte applikationer. Man kigger på de services og komponenter der benyttes og tilbydes, med udgangspunkt i en funktionel beskrivelse og med fokus på snitflader og beskrivelse af udvekslede data. Leverancen bør identificere komponenter der måske er implementeret flere gange, men med fordel kan trækkes ud som fælleskomponenter. Dette gøres ved at analysere hele applikationsporteføljen under ét. Dette er altså en komponentopdeling internt, af de enkelte applikationer. Det kan endda tænkes at der allerede er defineret fælles services i OIO regi disse bør det så overvejes at benytte. Eksternt ser bør man overveje hvilke applikationer man med fordel kan service-enable altså hvilke services de enkelte bør stille til rådighed for resten af verden, typisk som web services. Her bør man læne sig op af kriterier og retningsliner fra OIOXML/OWSA arbejdet. OIO EA trinbeskrivelser v1.0 Side 45 af 71 Februar 2007

46 5.3.6 Gode råd Nuværende arkitektur: Det giver værdi at have mange bidragsydere til at dokumentere denne, og komme relativt hurtigt i mål med oversigten over den nuværende arkitektur. Man bør også bestemme sig for hvem af de deltagende der fortsætter med at udarbejde den fremtidige arkitektur. Det bemærkes, at projekter der pågår også skal regnes ind under den nuværende EA. De fleste organisationer har ikke ret meget service-orientering i dag, og det giver således ikke altid mening at beskrive den nuværende arkitekturs service-orientering. Fremtidig arkitektur: SOA er et modeord for tiden, og man kan let komme ind i lange diskussioner om hvordan SOA defineres. Dette er næppe hensigtsmæssigt. SOA handler i bund og grund blot om at gøre fælles services fælles, og implementerede på en åben måde, under brug af internet teknologier som er tilgængelige for alle. Når man vil stille services til rådighed eksternt bør man gøre det via OIO s UDDI, som er en del af Infostrukturbasen. UDDI står for Universal Description Discovery and Integration. Med UDDI kan man: Definere servicen. Finde andre services. Dele information om hvordan services interagerer, i et globalt register. Man bør skelne mellem forretningslogik og services hvor forretningslogik er lidt mere primitivt (atomart). Eksempelvis kan forretningslogik være at slå en faktura op, mens servicen er at godkende fakturaen. Man bør også skelne mellem en service sådan som den er implementeret, og så den web service som man har aftalt med dem der skal bruge servicen. Det sidste kan være gennem en SLA (Service Level Agreement), hvor man har et fast interface, der ikke ændres selvom man ændrer i selve servicen (altså at ny funktionalitet i en service ikke påvirker dem der har baseret sig på aftalt funktionalitet; en versioneringspolitik) Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 46 af 71 Februar 2007

47 5.4 C4. Teknologiarkitektur Trinet beskriver den nuværende og den fremtidige teknologiarkitektur Formål Trinet beskriver den nuværende og den fremtidige teknologiarkitektur. Trinet fastlægger organisationens plan for brug af (strategiske) teknologier, på en måde der effektivt koordinerer udviklings-/vedligeholds-ressourcer og konsoliderer på nøgleteknologier Aktører EA arkitekt Teknologiarkitekt Organisationens netværks-, system- og øvrige teknologifolk Input Til nuværende applikationsarkitektur: Eksisterende dokumentation. Interview med it nøglepersoner. Til fremtidig applikationsarkitektur: Nuværende arkitekturer indgår. Specielt C4. Teknologiarkitektur (nuværende) skal være dokumenteret for at man meningsfyldt kan definere en fremtidig teknologiarkitektur og senere en migreringsplan fra nuværende til fremtidig (trin E2). A6. It-principper B2. Lokationer/organisation C1. Informationsarkitektur, C2. Applikationsarkitektur, og C3. Servicearkitektur Output Dette trin producerer to sæt OIO EA-produkter: ét der beskriver den nuværende informationsarkitektur, og et der beskriver den fremtidige informationsarkitektur ( as-is og to-be ). For både den nuværende og fremtidige arkitektur kan OIO EA output produkterne omfatte: C4.1 Teknologi referencemodel, der helt generelt præsenterer de teknologier organisationen for nuværende bruger, og hvad man fremover ønsker at standardisere omkring. C4.2 Arkitektur ByggeBlokke (ABB), der beskriver foretrukne konfigurationer nu og fremover. En konfiguration kan være en database server, en filserver, en administrativ arbejdsstation (pc), kontorklient, mv. C4.3 Systemtopologier, der generelt beskriver infrastrukturlandskabet for organisationen hvordan de enkelte ABBer kædes sammen i netværk. Igen vil der være nuværende og fremtidige systemtopologier eventuelt flere fremtidige, en om 2 år, en om 4 år, osv. C4.4 Udvidede systemtopologier, hvor også udvalgte applikationer er påførte, og flow af udvalgte informationsobjekter ligeledes vist. Disse bruges til at fokusere på tværgående funktioner, såsom sikkerhed eller system management, der kræver et samspil mellem applikationer, databasesystemer, netværksprotokoller, systemsoftware og hardware såsom servere, klienter og firewalls for at kunne virke. C4.5 Teknologi inventory, der er oversigten over de helt konkrete teknologier der anvendes servere med deres konfigurationer af processorer, RAM, ROM, IP-adresser; software med præcise versionsnumre og licensaftaler, osv. Denne leverance vil typisk kun være relevant for det nuværende miljø, men selvfølgelig opdateres løbende. Samlet set bør aktiviteten give en beskrivelse af organisations plan for brug af teknologier og standarder indenfor hardware, operativsystemer, database management systemer, netværksteknologi, messaging, middleware, sikkerhed, privacy, drifts- og system management værktøjer, udviklingsmiljøer, mv. OIO EA trinbeskrivelser v1.0 Side 47 af 71 Februar 2007

48 5.4.5 Metode Nuværende arkitektur: at afdække den nuværende arkitektur er i høj grad et arkæologi-arbejde. En EA arkitekt kan med fordel udvikle skabeloner til de dele af den nuværende arkitektur man vil afdække (jfr. Outputleverancerne). Disse udfyldes så af de af organisationens it-personer der har ansvar for de enkelte områder, ofte bistået af en leverandør. Det er vigtigt at bemærke følgende: Der er fire arkitekturområder: informations-, applikations-, service- og teknologiarkitektur, og dermed fire nuværende og fire fremtidige arkitekturer. Man dokumenterer dog ikke nødvendigvis alle, det er en del af tilpasningen af OIO EA metoden (trin A3) at definere hvilke der dokumenteres. Generelt: - Hvis man designer den fremtidige arkitektur indenfor et af de fire område, skal man dokumentere den nuværende indenfor dette område. - Hvis ikke man designer den fremtidige arkitektur indenfor et område, vil man ofte kunne spare at dokumentere den nuværende indenfor dette område, eller kun dokumentere den ret kortfattet. Dokumentation af nuværende arkitektur kræver ikke meget erfarne arkitekter udover en senior enterprise arkitekt til at skabe dokumentationsrammen og at overvåge og guide arbejdet, kan hovedparten af dataindsamlingen foretages af folk med noget mindre erfaring. Man kan med fordel dokumentere de nuværende arkitekturer i parallel. Ligeledes kan man indenfor en nuværende arkitektur definere de valgte output i parallel (én/flere dokumenterer applikationer, én dokumenterer integrationer, etc.). Høj grad af parallelitet fremmer at man hurtigere har grundlaget for at gå videre til designet af de fremtidige arkitekturer. EA arkitektens rolle i dokumentationen af den nuværende arkitektur er i høj grad at sikre konsistens og komplethed på tværs af områderne, og at rådgive om den ønskelige grad af detaljering der er krævet, for at sikre et godt fundament for den fremtidige arkitektur. De fleste organisationer har beskrevet dele af deres nuværende arkitektur, men i varierende grad af detaljering, komplethed og konsistens. Samtidig har mange organisationer svært ved at holde informationerne opdaterede. Der ligger en stor opgave for EA arkitekten i at sikre den indsamlede informations kvalitet, korrekthed og komplethed. Herudover har EA arkitekten opgaven med at sikre at organisationens medarbejde hjælper med at indsamle den information der indgår i dokumentationen af den nuværende. Dette er dog normalt ikke så vanskeligt, da området jo ikke er videre kontroversielt. Det kan være en relativt stor opgave at få dokumenteret den nuværende arkitektur. Til gengæld har en sådan oversigt en stor værdi, ikke blot for et EA projekt, men også for de teknologiprojekter der pågår i organisationen. Det er derfor en god ide allerede ved arbejdets begyndelse at have en plan for hvordan informationen vedligeholdes af hvem, under brug af hvilke værktøjer, hvordan vedligeholdelsespligten forankres, etc. En del af dette hører under Y3. EA governance. Fremtidige arkitektur: Hvor kortlægning af den nuværende arkitektur er en dokumentationsopgave, er udvikling af den fremtidige en designopgave. Denne kræver en hel anden grad af detaljeret fagdybde, og involverer en lang række specialister indenfor de enkelte arkitektur-områder, der hver især behersker metoder og teknikker indenfor området. Samtidig er området ofte meget følsomt, der kan være forskellige fløje i organisationen der advokerer forskellige teknologier. Teknologiarkitekturen skal naturligvis understøtte applikationerne, så det er vigtigt at se hvilke krav den fremtidige applikations- og informationsarkitektur stiller til den underliggende infrastruktur. Applikationer med særlige krav til eksempelvis svartider og sikkerhed kan indskrænke teknologivalget. De it-principper der blev defineret i A6 vil også være nyttigt input. I valg af teknologier bør man også skelne til en række andre forhold, såsom: Hvilke kompetencer der findes i organisationens it-afdeling(er), og hvilke man ønsker at udvikle. Eksisterende licensaftaler og andre forhold der påvirker prisen på teknologier. Herunder selvfølgelig ikke mindst om man ønsker at anvende open source-teknologier. Hvilke fremtidige teknologier man ser komme eksempelvis større brug af mobile løsninger. Hvordan lokationsmodellen i B2 influerer på systemtopologien. Hvorvidt man ønsker at lave en central integrationsplatform (en middleware integrationsbrooker). OIO EA trinbeskrivelser v1.0 Side 48 af 71 Februar 2007

49 Teknologiarkitekturen giver ikke mindst værdi ved at sørge for at ensrette brugen af tværgående teknologier. Ofte ser man en organisation bruge eksempelvis database management systemer fra 3-4 forskellige leverandør her vil en konsolidering ofte spare både i udvikling/vedligehold og i licenser. Teknologier der er specifikke for kun et enkelt, afgrænset forretningsområde er det måske næppe så vigtigt at få ind i arkitekturen. Teknologiarkitekturen bør række 3-5 år frem, og der bør derfor planlægges en udfasning af gamle teknologier og introduktion af nye. Nogle teknologier er taktiske nyttige nu, men ikke om flere år. Andre er strategiske også fremover. Andre igen bliver strategiske, men vil først nå et modenhedsniveau om nogle år. Teknologiarkitekturen bør omfatte gængse generelle teknologier, men også sektor-specifikke (såsom måleinstrumenter, køretøjer med it-udstyr, specialiseret kommunikation, osv.) Gode råd Nuværende arkitektur: Det giver værdi at have mange bidragsydere til at dokumentere denne, og komme relativt hurtigt i mål med oversigten over den nuværende arkitektur. Man bør også bestemme sig for hvem af de deltagende der fortsætter med at udarbejde den fremtidige arkitektur. Det bemærkes, at projekter der pågår også skal regnes ind under den nuværende EA. Fremtidig arkitektur: Som nævnt giver det god mening at lave en teknologi køreplan for teknologiernes forventede levetid og strategiske betydning. Denne bør revideres mindst én gang årligt Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. System topologi: OIO EA trinbeskrivelser v1.0 Side 49 af 71 Februar 2007

50 6 Aktivitet D: Gap analyse 6.1 D1. Restriktioner Formålet med trinet er at identificere restriktioner af teknisk og forretningsmæssig art, der skal tages højde for i udarbejdelsen af en migreringsstrategi og -plan Formål Formålet med trinet er at identificere restriktioner af teknisk og forretningsmæssig art, der skal tages højde for i udarbejdelsen af en migreringsstrategi og -plan Aktører EA arkitekt Forretningsarkitekt Applikationsarkitekt Teknologiarkitekt Informationsarkitekt It-chef, it-medarbejdere Forretningssiden Input Alle eksisterende leverancer kan indgå som input Output Output kan omfatte: D1.2 Risikoanalyse D1.1 Restriktioner, konsekvenser og alternativer, der indeholder: o - Beskrivelse af restriktioner (f.eks. økonomisystem X må ikke opgraderes ) o - Konsekvens af restriktion (f.eks. dobbeltregistrering koster længere sagsbehandlingstider ) o - Alternativ (f.eks. tilretning af økonomisystem Y vil koste Z kr. ) D1.2 Risikoanalyse, hvor man analyserer risici hvor alvorligt er truslen fra den enkelte risiko, hvor stor er sandsynligheden for at den indtræffer, hvad er den samlede påvirkning, og hvad kan man gøre for at imødegå den Metode Aktiviteten bør omfatte: Dokumentation af restriktioner. Det kan være forretningsmæssige (herunder politiske), økonomiske eller tekniske restriktioner. Eksempelvis en lovs ikrafttræden, en regional økonomisk afmatning, manglende support for gamle applikationer og teknologier, manglende opgraderingsmuligheder, at forretningsområder kræver at kunne fortsætte med en given applikation. Kvantificering af restriktionerne (f.eks. tidshorisont eller konsekvens). Det anbefales at lave en fast struktur for identificerede restriktioner. Dette gør versionering og løbende opdateringer muligt. Man kan udvide dette til at blive en egentlig risikoanalyse. Her vil man ikke blot beskrive kendte restriktioner, men også mulige forhindringer (restriktioner der måske/måske ikke kommer til at gøre sig gældende). For hver af dem bør man beskrive: OIO EA trinbeskrivelser v1.0 Side 50 af 71 Februar 2007

51 Vigtighed/betydning (hvor stor er skaden hvis truslen fra risikoen indtræffer høj/middel/lav) Sandsynlighed for at risikoen kommer til at ske (høj/middel/lav) Samlet påvirkning (vigtighed og sandsynlighed ganget sammen) Contingency hvad kan gøres for at rette op på det, hvis hændelsen indtræffer Gode råd Man bør løbende i forløbet med at udarbejde en enterprise arkitektur dokumentere restriktioner, efterhånden som de opdages. Typisk vil der være en restriktioner/risici Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 51 af 71 Februar 2007

52 6.2 D2. Muligheder Trinet identificerer 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 større kvalitet Formål Trinet identificerer 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 større kvalitet Aktører EA arkitekt Forretningsarkitekt Applikationsarkitekt Teknologiarkitekt Informationsarkitekt It-chef, it-medarbejdere Forretningssiden Input Alle eksisterende leverancer kan indgå som input Output Output er: D2.1 Muligheder, vigtighed og indsats. Et dokument der beskriver identificerede ikke-strategiske projekter, og mulige fordele som projekterne kan give. For hver af dem bør man anføre: o - Beskrivelse af projektet hvad går det ud på? o - Vigtighed/betydning af gevinsten målt på en høj/middel/lav skala, 1-10 skala eller andet. o - Indsats der skal til for at gennemføre projektet målt på en høj/middel/lav skala, 1-10 skala eller andet. o - Samlet nytte (vigtighed og indsats holdt op imod hinanden nemme projekter med høj betydning vil score højt). o - Ejer af muligheden Metode Metoden er egentlig blot at få sammenfattet og dokumenteret hurtige gevinster, lavthængende frugter som måske ikke er strategiske om fem år, men som på en kort tidshorisont kan tjene sig hjem. Der er altså tale om en anden slags muligheder end de der blev identificeret i A1 og var årsag til at man begyndte EA arbejdet. Der kan være tale om muligheder der retter sig mod organisatoriske forhold, mod teknologiske, eller andet. Indsatsområder kan ofte omfatte at se på leverandørforhold hardware-, software-og service-priser. Er organisationen på vej mod en strategisk arkitektur der ændrer leverandørernes rolle (enten til at være mere strategisk eller til at være mindre vigtig) vil man ofte kunne genforhandle kontrakter. Andre muligheder kan være af teknisk art; web frontends til applikationer, brug af nye kommunikationsteknologier (IP telefoni, mobile løsninger osv.). Det er vigtigt at spørge eksplicit ind til forbedringsmuligheder, bredt i organisationen. Når man udvikler en enterprise arkitektur, kommer man typisk meget rundt i organisationen, og i kontakt med mange med gode ideer, der bare aldrig er nået frem til it-afdelingen. Når mulighederne er samlet sammen i et dokument, bør man sammen med ejerne af mulighederne og andre interessenter samles (gerne i en workshop) for at prioritere hvilke der bør udføres hvornår. OIO EA trinbeskrivelser v1.0 Side 52 af 71 Februar 2007

53 6.2.6 Gode råd Man bør løbende i forløbet med at udarbejde en enterprise arkitektur dokumentere muligheder, efterhånden som de opdages Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 53 af 71 Februar 2007

54 6.3 D3. GAP analyse Formålet med GAP analysen er at analysere forskellene på den nuværende arkitektur ( as-is ) og den fremtidige arkitektur, ( to-be ), for derved at påbegynde planlægningen af denne migrering Formål Formålet med GAP analysen er at analysere forskellene på den nuværende arkitektur ( as-is ) og den fremtidige arkitektur, ( to-be ), for derved at påbegynde planlægningen af denne migrering Aktører EA arkitekt Applikationsarkitekt Informationsarkitekt Teknologiarkitekt Input Den nuværende og fremtidige arkitektur, som defineret i C1. Informationsarkitektur, C2. Applikationsarkitektur, C3. Servicearkitektur og C4. Teknologiarkitektur A2. EA governance strategi D1. Restriktioner, D2. Muligheder Output Output er: D3.1 Gap analyse.. For hver at de fire hovedområder i den teknologiske del af arkitekturen information, applikation, service og teknologi beskrives hvilke forskelle der er i det nuværende og det fremtidige; og hvordan i store træk man kunne tænke sig at komme fra as-is til to-be. Der vil typisk være flere måder at lukke gapet på, og her er det vigtigt med en grundig analyse af fordele og ulemper af hver af disse, samt en klar anbefaling Metode For hver at de fire hovedområder i den teknologiske del af arkitekturen information, applikation, service og teknologi skal man analysere forskellen på den nuværende og den fremtidige arkitektur. Denne analyse kræver en lang række arkitekter og tekniske eksperter, og en egentlig metode er svær at skitsere. Det er vigtigt at undersøge forskellige måder at komme fra as-is til to-be, og at analysere fordele og ulemper ved disse. Typisk vil der være: Big bang. Eksempel: Man implementerer et helt nyt system og fjerner mainframen. Evolution. Eksempel: Man migrerer gradvist applikationerne 1:1 fra mainframen til decentrale systemer. Det vil sige at applikationerne overføres til en ny platform, men fortsætter enkeltvis som de var, blot på ny teknologi. Komponentopdeling. Eksempel: Man søger at komponentopdele de eksisterende mainframe applikationer. Kun derefter begynder man at gå over til at lade mainframe-versionen af en komponent erstattes af en tilsvarende web service. Co-eksistens. Eksempel: Man migrerer visse mainframe applikationer, men lader andre leve Gode råd Gap analysen kan med fordel overveje hvilke afhængigheder der er i forskellene mellem as-is og to-be. Altså eksempelvis om en evolution overhovedet er mulig, eller om man står med en brændende platform, hvor kun data kan videreføres, mens applikationerne med fordel kan skrottes, frem for at udvikles Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 54 af 71 Februar 2007

55 7 Aktivitet E: Forandring 7.1 E1. Migreringsstrategi Formålet er at udarbejde en overordnet ramme for migreringen, hvor de forretningsmæssige ønsker til migreringen fastslås Formål Formålet er at udarbejde en overordnet ramme for migreringen, hvor de forretningsmæssige ønsker til migreringen fastslås. Ligeledes afdækkes de rammer som organisatoriske hensyn sætter. ( Migrering er brugt i en bred forstand, og dækker over overgangen fra en tilstand til en anden. Migrering dækker over opgradering, nye systemer og services, systemer og services der fjernes osv) Aktører EA arkitekt Forretningssiden IT Chef Input A6. It-principper Input fra B. Forretning - især B4. Forretningsprocesser Input fra alle C. Teknik-leverancer ikke mindst C1. Informationsarkitektur D3. Gap analyse X1. Forretningsmæssige trends og X2. Tekniske trends. Y1. Driftssituation, Y2. Budget og ressourcestyring, Y4 Lovmæssige bindinger, og Y5 Kontrakt og aftaleforhold Output Output er: E1.1 Migreringsstrategi. Et mindre dokument, der sætter den overordnede ramme for migreringsprojekterne. For eksempel: o - Er der præference for big bang eller gradvise migreringer (ønsker virksomheden at påtage sig en høj risiko for at høste store gevinster). Dette er diskuteret i D3 gap analysen, her dokumenteres konklusionen. o - Hvordan vurderes migreringsprojekter (f.eks. økonomisk model for kortsigtsgevinster i forhold til langtidsgevinster). o - Mange migreringsprojekter opstår fordi der er en ændring til arkitekturen. Hvor vigtig er disse i forhold til andre efterspørgere? Implementeres nye krav til arkitektur (herunder standarder) altid når der alligevel laves om? Dokumentet skal placere ansvaret for migreringsprojekter orgisatorisk i f.eks. en projektorganisation eller linieorganisation herunder hvor den overordnede projektledelse er forankret Metode To centrale aktører indgår i at fastlæge migreringsstrategien. Systemejerne repræsenteret ved forretningssiden, og de driftsansvarlige. Forretningssiden vil formentlig mest afstikke de organisatoriske rammer hvordan ønsker forretningssiden at indgå i migeringsprojekter, og er der områder der er pålagt eksterne eller juridiske restriktioner, som vil påvirke migreringsprojekter? Forretningssiden vil have masser input til hvad der er vigtigt, men husk at det kun er strategien, som fastlægges i dette trin. OIO EA trinbeskrivelser v1.0 Side 55 af 71 Februar 2007

56 Hvis it-driften er outsourcet, vil kontraktlige forhold næsten altid påvirke migregringsstrategien. Der kan også være økonomiske forhold, som ikke er strategiske, men som i praksis altid vil påvirke strategien. It-driften vil typisk have strategier for migreringer, som kan overtages. Arkitekturdokumenterne B4, C1-C4 indeholder rammerne for migreringsprojekter og betyder mest for migreringsplanlægningen. Der han derudover være vigtige principper, som skal respekteres når systemer migreres (f.eks. organisering af data, brugerstyring, serviceorientering), men disse skal kun medtages hvis de er strategiske! Gode råd Husk at strategien skal hjælpe i efterfølgende planlægning. Strategien bør hjælpe med at give svar til situationer som disse eksempler: Den forretningskritiske applikation XYZ skal opdateres, men kan ikke understøtte vores ønske om serviceorientering. Applikation ABC kan klare dette, men omfatter en stor konvertering til stor gene/omkostninger for vores brugere. Udrulning af OpenOffice medfører at vores forretningskritiske Excel spreadsheets skal restruktureres. Det betyder ekstraarbejde for vores sagsbehandlere de næste 18 måneder. Migreringsplanlægningen (E2) er i realiteten prioritering i forhold til hvad der organisatorisk, økonomisk og tidsmæssigt muligt. Det er vigtigt at fange grundlæggende elementer i migreringsstrategien, men ikke at blive alt for operationel Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 56 af 71 Februar 2007

57 7.2 E2. Migreringsplan Højniveau projektplan for de kommende års migreringsprojekter. For hvert enkelt grovestimeres, en detaljeret projektplan udarbejdes senere Formål Højniveau projektplan for de kommende års migreringsprojekter. Hvert enkelt grovestimeres, en detaljeret projektplan udarbejdes senere. Trinet omfatter blandt andet: Prioritering af projekter. Identificering af migreringspakker (f.eks. IP telefoni, sammenlægning af AD-struktur ). Udvikling af en højniveau migreringsplan Aktører EA arkitekt IT Chef Projektledelse (forandringsledelse) Input C1. Informationsarkitektur, C2. Applikationsarkitektur, C3. Servicearkitektur, C4. Teknologiarkitektur D1. Restriktioner, D2. Muligheder, D3. Gap analyse E1. Migreringsstrategi Output Output er: E2.1 Migreringsplan, der typisk omfatter: o - Projektoversigt: hvilke strategiske EA projekter skal gennemføres over de næste 3-5 år, og hvad er deres indbyrdes afhængigheder og rækkefølge de implementeres i. o - Projektbeskrivelse af de enkelte projekter: aktiviteter og mål med projektet, beskrivelser af projektkrav til resourcer (personer/kompetencer, software/hardware-krav, etc), grovestimater på tidsplaner (start/slut, mandmåneder, etc.) og priser, mulige interne og eksterne leverandører, osv Metode Der kan tages udgangspunkt i de følgende forhold, hvoraf mange er belyst i foregående EA trin (angivet i parentes hvor svar bl.a. vil kunne findes): Hvilke afhængigheder er der mellem dette projekt og andre projekter og aktiviteter? (bør findes beskrevet i D1 og D2) Hvilke produkter er der behov for? (C1, C2, C3 og C4) Hvilke komponenter skal udvikles? (B3, C4) Har vi de fornødne ressourcer til en sådan udvikling? Hvilke åbne standarder skal produkter og komponenter understøtte? (C3, C4) Hvornår er de tilgængelige? Er produkterne holdbare dels fordi teknologien og standarderne, der understøttes er fremtidssikret og dels fordi leverandøren er troværdig Hvad vil det koste at uddanne brugerne i nye systemer? Hvad koster migreringen og hvilke fordele får vi? Opdel fordele i konkrete og målbare og ikke målbare. (D2) Er migreringen praktisk mulig? (D1) Migreringsplanen kan med fordel dokumenteres i et Gant-chart, med tilhørende detaljer for de enkelte projekter. OIO EA trinbeskrivelser v1.0 Side 57 af 71 Februar 2007

58 7.2.6 Gode råd Modellen kræver ikke detailplanlægning af de enkelte migreringsprojekter men kræver derimod et vist kendskab til de forskellige projekter. F.eks. indførelse af IP telefoni, opgradering af netværks infrastruktur og teknisk infrastruktur vil formentlig have overlappende funktionalitet og krav til hinanden. Dette skal afklares i dette trin og kræver en vis grovplanlægning og analyse Eksempler Eksempel baseret på SKATs arkitekturarbejde. Figuren er et eksempel på hvordan output kan dokumenteres men indholdet er ikke nødvendigvis korrekt. Migreringsplan: OIO EA trinbeskrivelser v1.0 Side 58 af 71 Februar 2007

59 7.3 E3. Konsekvensanalyse Trinet afdækker konsekvenserne af de foreslåede projekter hvad betyder de for kunderne og brugerne? Formål Trinet afdækker konsekvenserne af de foreslåede projekter hvad betyder de for kunderne og brugerne? Konsekvensanalysen bør indeholde en indsatsplan for de områder hvor konsekvenserne kan være store. Dette kan blandt andet omfatte at sikre at brugerne føler sig trygge ved de ændringer der kommer Aktører EA arkitekt Systemejer Projektleder It-forretningskonsulent Input E2. Migreringsplan Output Output er: E3.1 Konsekvensanalyse, der for hvert migreringsprojekt identificeret i E2 beskriver: o Årsager til konsekvens ( fastnet-telefonen erstattes af mobil )- Konsekvenser ( brugerne føler de ikke har fri, så nogle vil blive mere stressede, vi kan ikke tage hinandens telefon og det vil blive opfattet som dårlig kundeservice, lettere at arbejde hjemme ) o Indsats ( brug af telefonnumre, omstilling, politik for telefonsvarermeddelelser, hvor må man snakke i telefon uden at forstyrre andre? ) Under konsekvensanalysen kan man opdage nye sammenhænge og det vil ofte være praktisk at samle projekter i pakker, der er tæt forbundne eller har de samme konsekvenser ( når nu fortovet skal graves op skulle vi så ikke smide både el-ledninger og de nye gasledninger ned samtidig ) Metode Der findes ingen formel metode, men der kan tages udgangspunkt i følgende vigtige spørgsmål: Hvilke implikationer har dette projekt på andre projekter og aktiviteter? Hvad vil det koste at uddanne brugerne og supporterne i nye systemer? Hvilken kulturændring kræves af brugerorganisationen, og hvordan kan det bedst styres? Hvordan påvirkes forretningsgange og arbejdsgange? Konsekvensanalysen kan gennemføres som en risikoanalyse, og bør sammentænkes med restriktionerne identificeret i D1. Alle konsekvenser kan opfattes som risici (positive eller negative) og dette giver en struktureret tilgang, f.eks.: Identifikation Analyse og prioritering Planlægning Opfølgning og rapportering Udførelse Læring Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 59 af 71 Februar 2007

60 8 Aktivitet X: Tekniske og forretningsmæssige trends 8.1 X1. Forretningsmæssige trends Formålet er at udarbejde en oversigt over de forretningsmæssige trends, som kan tænkes at skulle arbejdes ind i it-arkitekturen Formål Formålet er at udarbejde 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, og som derfor kan være nødvendigt at tage hensyn til i arkitekturen. Eksempelvis er outsourcing og brug af shared services to trends for tiden Aktører Forretningsarkitekt Forretningssiden It chef Input Organisationens forretningsstrategi, årsrapport, og lignende. Interview med ledere på tværs af organisationen. Analyser og rapporter vedrørende den pågældende sektors område (omkring Danmark og rapporter fra tilsvarende sektorer i udlandet). Publikationer fra Administrationspolitisk center i Finansministeriet og fra IT- og Telestyrelsen Output Output er: X1.1 Forretningmæssige trends. Dette dokument opsummerer og prioriterer de forretningsaspekter der senere vil indgå i trin A1 og A Metode Dette er en indsamling af de forretningsmæssige trends der senere kommer til at blive konkretiseret i trin A1. EA-relaterede udfordringer, og sammenfattet i trin A5. Vision, mål og strategier. Så metoden er at indsamle information bredt, via både eksterne kilder (såsom rapporter fra analysebureauer) og via interne (visioner hos ledere). I A5 konsolideres disse og konkretiseres til forretningsstrategier, så der dannes et samlet billede af organisationens forretningsmæssige prioriteter. Forretningsarkitekten er en anker-person i at sikre denne informationsindsamling. I dette trin kan man eventuelt også lave en analyse af organisationens stærke og svage sider, muligheder og trusler (en såkaldt SWOT-analyse Strengths, Weaknesses, Opportunities and Threats ). Alternativt laves denne i A Gode råd Ved interviews med forretningssiden bør der tages referat, og disse referater bør godkendes af de interviewede Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 60 af 71 Februar 2007

61 8.2 X2. Tekniske trends Formålet er at udarbejde en oversigt over de tekniske trends som er oppe i tiden, og som kan overvejes taget ind i enterprise arkitekturen Formål Formålet 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 er at lave arkitekturen service-orienteret (SOA). Brugen af OIOXML er en anden. Mobilitet en tredje. Der er også metodemæssige trends såsom it-governance rammeværket ITIL og enterprise arkitektur metodes som OIO EA Aktører EA arkitekt Teknologiarkitekt Applikationsarkitekt (Informationsarkitekt) It-chef Input Rapporter og analyser fra analysebureauer, teknologileverandører og andre eksterne kilder. Interviews med teknologi-ansvarlige og visionære i organisationen Output X2.1 Tekniske trends. Her gives en oversigt over hvilke tekniske it-trends der vil kunne påvirke enterprise arkitekturen,. Vurderingen resulterer i anbefalinger til hvilke teknologier der bør ind- eller udfases, hvornår og indenfor hvilke områder Metode Man må opsamle de tekniske trends der er fremherskende i tiden. For hver kan man anføre: Navn og en kort beskrivelse. Modenhed for den pågældende trend man kan anføre forventet modenhed for de kommende 3-5 år. Man kan passende benytte en skala til modenheden, for eksempel: på eksperimentstadie (bliver måske ikke til noget) på vej moden på vej ud (erstattes af noget andet). Det vil typisk være sådan at man bør begynde at interessere sig for teknologiske trends der synes at være over eksperimentstadet og med stor sandsynlighed bliver til noget. Relevans for organisationen. Også relevansen kan man med fordel specificere for et par år ud i fremtiden, således at man angiver hvornår teknologien bør inddrages, og hvordan. Også her kan man indføre en skala, såsom: vent i pilot fuld implementering udfas. Eventuelt en kort note med yderligere præcisering for eksempel af hvor teknologien bør indføres, og hvordan man agter at sikre sig kompetence til at håndtere den ny teknologi. En teknisk trend er ikke kun at noget er på vej ind det kan også være en trend at en teknologi er på vej ud. Sådanne trends bør man også forholde sig til Gode råd I vurderingen af relevans kan man med fordel vurdere organisationens generelle teknologi-tilpasningstempo. Indenfor nogle forretningsområder er det essentielt at være teknologiførende. Andre organisationer står sig fint ved ikke at kaste sig ud i det nyeste nye hele tiden, men derimod være moderate, og først tilegne sig ny teknologi, når der er en vis modenhed. OIO EA trinbeskrivelser v1.0 Side 61 af 71 Februar 2007

62 I vurderingen af ny teknologi spiller det naturligvis også ind hvilke kompetencer der findes i organisationen, og tage højde for at nogle medarbejdere motiveres ved løbende at arbejde med ny teknik, hvorimod andre foretrækker at udvikle yderligere kompetence indenfor de områder de allerede er fortrolige med. Afgrænsede pilotprojekter vil ofte kunne sige noget både om hvorvidt en teknologi vil være nyttig for organisationen, og om man er klar til at tage den i anvendelse Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 62 af 71 Februar 2007

63 9 Aktivitet Y: Principper og styring 9.1 Y1. Driftssituation Formålet er at udarbejde og vedligeholde en sammenhængende driftssituation Formål Formålet er 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. Der er derfor god grund til at indføre best practice principper for it-driften Aktører Forretningsarkitekt Teknologiarkitekt It chef / driftschef Input Y3 EA governance er et nøgleinput, men de fleste EA-leverancer vil blive brugt i driftsmiljøet. Eksisterende dokumenter om driftsmiljøet Output Output er: Y1.1 Driftsdokumentation. En portefølje af dokumenter der tilsammen dokumenterer driftsmiljøet og driftsprocedurer. Dokumenttyperne kan være som beskrevet nedenfor. Y1.2 Driftsoperation, der afspejler den aktuelle driftssituation (og altså er en immateriel leverance). Output skulle gerne lede til en sikker styret driftssituation. Denne kan være beskrevet og implementeret ud fra en række dokumenter, der kan omfatte: En definition af roller og processer i driftssituationen. Det er essentielt at alle henvendelser vedrørende driften får identificeret en ejer og følger en veldefineret proces. I EA sammenhæng er specielt helpdesk funktionen vigtig. Det er vigtigt at have en måde at få ændringsønsker filtreret på, således at der etableres en helpdeskfunktion, der jo genererer ændringsønsker der kan påvirke arkitekturen. Brugervejledninger, som i detaljer fortæller brugeren, hvorledes et givet system skal anvendes. Installationsvejledninger, som i detaljer fortæller en tekniker, hvorledes systemet skal installeres og konfigureres. Systemdokumentation, der er dokumentation af it-systemer og data, samt disses interaktion (typisk dataudveksling) med hinanden. Testbeskrivelser, der beskriver hvordan test af et system skal gennemføres. Testrapporter, som dokumenterer gennemførelsen af en test af et system (eller et modul) ud fra en testbeskrivelse. En sikkerhedsanalyse, der vurderer den samlede mængde af beskyttende foranstaltninger, der skal sikre virksomhedens driftsmæssige kontinuitet og minimere afledte risici og tab ved misbrug af systemer og information. En sikkerhedspolitik, der beskriver hvorledes en myndighed, eller flere myndigheder inden for samme domæne, gennemfører den samlede mængde af beskyttende foranstaltninger, der skal sikre virksomhedens driftsmæssige kontinuitet og minimere afledte risici og tab ved misbrug af systemer og information. OIO EA trinbeskrivelser v1.0 Side 63 af 71 Februar 2007

64 DS 484 normen er meget relevant her. Den finder anvendelse inden for planlægning, projektering, opbygning og opretholdelse af tekniske og administrative sikringsforanstaltninger til forøgelse af sikkerheden for it-systemer og -anlæg. IT- og Telestyrelsen har indgået en aftale med Dansk Standard, der giver alle statsinstitutioner ret til gratis at benytte DS 484 i forbindelse med institutionernes sikkerhedsarbejde. Service Level Agreements (SLAer), der beskriver de serviceaftaler organisationen kan forvente, med hensyn til for eksempel svartider på forskellige henvendelser, oppetider, system-svartider, og så videre. Service katalog: Et relevant punkt vil også være etableringen af et servicekatalog som beskriver hvilke services helpdesken har ansvaret for at supportere. Configuration Management database (CMDB): Et andet vigtigt omdrejningspunkt er etableringen af en CMDB, som skal give helpdesk og driftsfolk mulighed for at få overblik over de elementer og sammenhænge i it-infrastukturen, som ligger til grund for de it-services der udbydes.. Dette er specielt relevant ved fejlbeskrivelser og rettelser af it-problemer og ved planlægning og udførsel af ændringer i it- infrastrukturen Metode ITIL er en af de mest veludviklede metoder indenfor service management, og er hurtigt ved at blive en af de mest anvendte Gode råd Det er essentielt at alle henvendelser vedrørende driften får identificeret en ejer og følger en veldefineret proces. Der bør identificeres mål for nøgletal på driften, og der bør etableres en procedurer der sikrer at disse reviewes, og erfaringer uddrages. Helpdesken bør være den samlende kontaktflade ( single point of contact ) mellem driften og it-brugerne Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 64 af 71 Februar 2007

65 9.2 Y2. Budget og ressourcestyring Formålet er at styre porteføljen af foreslåede projekter der har EA relevans (pga. størrelse og/eller strategisk vigtighed), og herunder prioritere og allokeres ressourcer (arbejdstid, penge) Formål Formålet er at styre porteføljen af foreslåede projekter der har EA relevans (pga. størrelse og/eller strategisk vigtighed), og herunder prioritere og allokeres ressourcer (arbejdstid, penge). Aktiviteten kan også give anledning til budget-ændringer Aktører Forretningsarkitekt EA arkitekt Forretningssiden, herunder finanskontrollere og økonomisiden. It-chef Input Blandt de mange EA leverancer, er der navnlig to der kan vejlede i budget- og ressourcestyringen, er: E2 Migreringsplan, der definerer de strategiske projekter der skal implementere enterprise arkitekturen. Y3 EA governance, der definerer de overordnede rammer for denne implementering Output Output er: Y2.1 Budget og ressourcer. En 3-6 månedlig opdateret plan over hvilke større it-projekter der er at vente de næste 3-5 år, med en foreslået budgetallokering til disse, og med rationale for disse allokeringer Metode I dette trin reviewes løbende: 1. De strategiske projekter der er foreslået i trinet E2 Migreringsplan, hvor strategiske EA implementeringsprojekter er beskrevne og estimerede. Disse reviewes løbende i trin Y3. EA governance, og budgetteres altså her. 2. De taktiske it-projekter der foreslås fra andre steder i organisationen, projekter der så at sige dukker op. Det kan være projekter der ikke nødvendigvis er meget EA-relevante, men af mere taktisk karakter, men som alligevel har en budgetmæssig ramme så de kan influere på budgetteringen af EAstrategiske projekter. Dette kan være projekter der er nødvendige (såsom udskiftning af kabler i forbindelse med en flytning) eller taktiske (såsom at en leverandør har givet et godt tilbud på udskiftning af ældre arbejdsstationer). Det er relevant at holde de økonomiske gevinster og andre fordele, som taktiske projekter (2. ovenfor) kan give, op imod de mere langsigtede fordele som strategiske EA projekter vil give, og ud fra dette prioritere. Som rettesnor for prioriteringerne kan man bruge en hel del af det output som et enterprise arkitektur-projekt har produceret ikke mindst leverancerne fra trin E2 migreringsplan Gode råd Taktiske it-projekter bør naturligvis være i overensstemmelse med enterprise arkitekturen. Når de kaldes taktiske er det fordi de repræsenterer en nødvendig investering, eller en besparelse der er værd at tage. De er således ikke dårligere end strategiske EA projekter, men de leder ikke i sig selv til en markant større opnåelse af målene med enterprise arkitekturen Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 65 af 71 Februar 2007

66 9.3 Y3. EA governance Formålet med dette trin er i høj grad at sikre at alle de aktiviteter der har fundet sted og leverancer der er blevet produceret, i EA forløbet, nu bindes sammen til noget der bevæger organisationen hen imod den definerede EA Formål Hovedformålene med denne aktivitet er at sikre at arkitekturen: publiceres/kommunikeres til alle interne og eksterne interessenter overholdes at alle projekter af en vis størrelse og taktisk betydning evalueres for at sikre at de overholder arkitekturen, og/eller at afvigelser bevidst godkendes. implementeres at projekter proaktivt initieres for at sikre fremdrift hen imod den fremtidige arkitektur. overvåges og opdateres således at teknologiske, organisatoriske, forretningsmæssige og andre ændringer afspejles i arkitekturen. Der er varierende grad af hvordan styringen foretages, se nedenfor. Formålet med dette trin er altså i høj grad at sikre at alle de aktiviteter der har fundet sted og leverancer der er blevet produceret, i EA forløbet, nu bindes sammen til noget der bevæger organisationen hen imod den definerede EA Aktører EA arkitekt Projektledelse (forandringsledelse) It og forretningsledelse Input Alt, men ikke mindst A2. EA governance strategi og Y3. Budget- og ressourcestyring Output EA governance strategien blev fastlagt i A2 EA governance strategi. Nærværende trin uddyber og operationaliserer denne strategi, og etablerer organisation og processer. Dette arbejde er allerede påbegyndt i trin A2, og bør ske løbende i EA projektet. Output omfatter: Y3.1 EA governance beskrivelse. Et EA governance dokument der sætter rammer for EA governancen, og beskriver: o EA organisationsstruktur, med styregruppe(r), arbejdsgrupper, en enterprise arkitekt rolle, etc. o Review processer, således at projekter/programmer reviewes imod EA. o Vedligeholdelsesprocesser, således at EA løbende holdes opdateret. o Kommunikationsprocesser, således at EA formidles, internt og eksternt. (Y3.2 EA governance implementering). Eksekvering etablering af EA organer, start på EA processer og dermed EA governancen. Til grund for outputtet ligger de overvejelser om styringsmodeller der blev foretaget i A Metode Nedenfor er anført hovedaktiviteter, som bør overvejes gennemført i EA governance. EA organisation: Konstituering af EA governance organer. Disse kan omfatte: En EA styregruppe, der fastlægger vision, mål og strategier for en EA, arkitekturen, træffer overordnede beslutninger, og afsætter resourcer til EA s fortsatte vedligehold. Medlemmer her er fra virksomhedens øverste ledelse, både stabs- og linieområder, og fra både forretning og teknik. OIO EA trinbeskrivelser v1.0 Side 66 af 71 Februar 2007

67 Et EA Review Board (EARB), der mødes ca gange årligt og træffer beslutninger vedr. arkitekturen, reviewer/prioriterer projekter og indsatsområder der relaterer sig til EA, initierer arbejdsgrupper og andre initiativer der skal vedligeholde EA, reviewer resultatet af disse, og eskalerer til styregruppen om nødvendigt. Medlemmerne bør rekrutteres fra forretning og teknik, og er personer med pondus i deres egen organisation, og et bredt udsyn. EA Task Force (EATF)s, der nedsættes på foranledning af EARB, for at afdække et teknisk og/eller forretningsmæssigt område der kan påvirke EA; indgå med EA-ekspertise i projekter eller på anden måde fremme EAen. En EATF vil levere beslutningsgrundlag til EARB. En EA (chef)arkitekt, der evt. bistået af et EA sekretariat varetager mange af daglige, praktiske opgaver i EA governance arbejdet. Herunder at være i tæt kontakt med EA-relaterede initiativer i og udenfor organisationen, på baggrund af dette proaktivt foreslå initiativer, forberede møder, følge op på konklusioner, være daglig kontakt til EATFer og andre EA interessenter, mv. EA sekretariatet kan også have ansvaret for at EA i praksis dokumenteres og publiceres løbende. Processer: Definition og igangsættelse af EA processer. Disse kan omfatte: EA projekt review processer. Der skal eksistere klare, gennemsigtige og veldokumenterede processer omkring review af projekter, prioriteringer imellem disse, og måske egentligt portefølje management. Dette kan f.eks. omfatte hvornår der kan dispenseres, metode til konsistent vurdering af projektets værdi, krav til ansøgende projekter og så videre. Man vil sikkert foretage review på forskellige tidspunkter i et projekts levetid: o Pre-projekt vurdering, som er en vurdering af hvor relevant et projekt er i EA sammenhæng, og planlægger yderligere EA audits ud fra dette. o EA projekt reviews, hvor EA compliance planlægges, fremdrift vurderes, og afvigelser godkendes/afvises. o EA post-projekt vurdering, hvor relevante erfaringer fra projektet opsamles og indarbejdes i EA. EA vedligeholdelsesprocesser. Enterprise arkitekturen skal kontinuert holdes opdateret og understøtte forretningen. Der bør foretages periodiske målinger af om enterprise arkitekturen adresserer de udfordringer som blev dokumenteret i A1 EA-relaterede udfordringer. Der kan tænkes følgende vedligeholdelsesprocesser: o EA teknologi-overvågning, hvor man overvåger teknologiske trends der bør få betydning for EA, og laver anbefalinger ud fra dette. o EA forretnings-overvågning, hvor man overvåger lovgivnings/markeds/brugermæssige tendenser, og laver anbefalinger ud fra dette. o EA ændringsønske-behandling, der dels giver mulighed for at alle relevante interessenter kan komme med ændringsønsker/forslag, dels kan behandle disse, og dels synliggøre disse. o EA dokumentation den konkrete vedligehold af EA i de valgte værktøjer og rammer. EA kommunikationsprocesser. Barrieren for en succesfuld enterprise arkitektur er oftest at den ikke er kendt eller forstået. En EA må ikke drukne i procesdokumentation, men skal bruges i det daglige når der planlægges og laves arkitektur i praksis. Kommunikation kan indeholde: o EA forklaring: rollespecifikke og praktiske vejledninger (f.eks. hvad betyder arkitekturen for udvikleren o EA publikation: opdateret og lettilgængelig dokumentation (intranet, værktøjsintegration). En tilgængelig EA gør det lettere for andre at genbruge og forbedre den. o EA evangelisering; høj synlighed i organisationen. Omfatter præsentationer, kommunikation af succeshistorier, mv Gode råd Det er vigtigt at de organisationsstrukturer og processer, der foreslås her, allerede etableres mens et EA projekt er undervejs. Herved sikres en flydende overgang fra udarbejdelsen af en EA arkitektur til implementeringen af denne. Trin A2 EA governance strategi er ment til at starte EA governance, men bør løbende glide over i at dette trin Y3 udføres, i parallel med udarbejdelse af enterprise arkitekturen. En EA governance praksis kan fastlægges uden at der er en egentlig migreringsplan til stede, og i dette tilfælde er EA governance endnu meget vigtig. I så fald holder man de enkelte projektforslag op imod arkitekturen, og udøver governance den vej. Har man lavet en egentlig EA migreringsplan, skulle de vedtagne projekter OIO EA trinbeskrivelser v1.0 Side 67 af 71 Februar 2007

68 forhåbentlig lede til realisering af den fremtidige EA. Men selv her bør der være governance, idet verden jo ikke står stille imens projekterne implementeres. Det er vigtigt at bemærke at EA governance og it governance er forskellige ting; de er overlappende, men ikke identiske. EA governance dækker bredere (mere forretning), mens it governance går dybere. It governance beskæftiger sig således med etablering af en it driftsorganisation og dennes arbejdsgange, med styring af serviceaftaler, mv. områder som er vigtige, men lidt udenfor en EAs mål om at styre på de store linier. It governance har også en mere daglig indflydelse på it budgetstyring. Ifølge MIT Sloan (CISR WP No. 349, Weill and Ross, 2004) omfatter it governance beslutninger og styring af følgende fem store områder: It principper: Beslutninger på højt niveau om den strategiske rolle, som IT spiller for virksomheden. It arkitektur: Et integreret sæt af tekniske valg som hjælper organisationen med at opfylde kravene til virksomheden. It infrastruktur: centralt koordineret, fælles IT-services som understøtter virksomheden forretningsfundament og typisk oprettet inden præcise behov var kendt (historisk evolution). Behov for forretningsapplikationer: forretningskrav til indkøbte eller internt udviklede applikationer. Prioritering og investering: beslutninger om hvor meget og hvor der skal investeres i IT. Nærværende OIO metode er en arkitekturmetode, og omfatter EA governance i bred forstand. Fælles med definitionen anvendt i MIT Sloan ovenfor skal Y3 EA governance : Sikre at it principperne bliver fulgt. Sikre at den fastlagte enterprise arkitektur bliver fulgt og implementeret i praksis. Sikre at it og investeringerne understøtter virksomhedens forretningsmål. Prioritere investeringerne i forhold til arkitekturen (og dermed forretningsmålene) Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 68 af 71 Februar 2007

69 9.4 Y4. Lovmæssige bindinger Trinet tjener til at udarbejde en oversigt over danske love og EU-direktiver og -regulativer der er relevante for en given organisations it-brug Formål Trinet tjener til at udarbejde en oversigt over danske love og EU-direktiver og -regulativer der er relevante for en given organisations it-brug. Formålet med dette er at sikre, at man tager højde for disse i enterprise arkitekturaktiviteter, såsom udarbejdelse af en kravspecifikation, beskrivelse af fremtidige services, eller noget tredje Aktører Forretningssiden, herunder jurister og indkøbere Eksterne eksperter, indenfor dansk og EU-ret, Datatilsynet, SKI-aftaler, mv. Forretningsarkitekt It chef Input Foreliggende danske love og beslutningsgrundlag. Foreliggende EU-forordninger og direktiver. Bemærk at forordninger er gældende lov i hele EU, mens direktiver fortolkes lokalt. Indenfor it er det primært direktiver der anvendes. Organisationens egne love og etiske kodeks kan indgå Output Output er: Y4.1 Lovmæssige bindinger. Et dokument der kort resumerer de lovmæssige hensyn der er relevante for fremtidige it- og it-relaterede projekter Metode Metoden er at høre den lovmæssige ekspertise der findes i organisationen, samt at opsamle den erfaring der er blevet indhøstet fra konkrete projekter. Samtidig bør man løbende følge de EU-direktiver og forordninger der vedtages, og de lovforslag Folketinget vedtager. Man bør for hver lov kort beskrive (i) hvad den omhandler og fordrer, (ii) hvor bindende den er, og (iii) en reference til selve lovteksten, hvor muligt Gode råd Følgende love er blandt de relevante: Fagspecifik lovgivning Offentlighedsloven Forvaltningslov (lov nr. 571) Lov om behandling af personoplysninger (lov nr. 429 af 31. maj 2000 som ændret ved lov nr. 280 af 25. april 2001) er relevant i mange it-sammenhænge. Se evt. datatilsynets hjemmeside. Lov om videreanvendelse af den offentlige sektors informationer (lov nr. 596 af 24/06/2005). Dette er en fortolkning af Europa-Parlamentets og Rådets direktiv 2003/98/EF af 17. november 2003 om videreanvendelse af den offentliges sektors informationer (PSI Public Sector Information). Det offentliges bevægelse hen i mod større brug af åbne standarder senest markeret ved Beslutningsgrundlag B.103 af 2. juni 2006 om brug af åbne standarder er endnu ikke udmøntet i lov, men man bør alligevel betragte det som en forventet lovmæssig binding Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 69 af 71 Februar 2007

70 9.5 Y5. Kontrakt og aftaleforhold Formålet er at udarbejde en oversigt over de indgåede aftaler der er relevante at tage i betragtning ved udviklingen og implementeringen af en enterprise arkitekturs it-elementer Formål Formålet er at udarbejde en oversigt over de indgåede aftaler der er relevante at tage i betragtning ved udviklingen og implementeringen af en enterprise arkitekturs it-elementer. Med sådan en oversigt kan man nemlig bedre tilrettelægge planen for implementeringen af enterprise arkitekturen både drage nytte af eksisterende aftaler, og sikre at man ikke bryder indgåede aftaler Aktører EA arkitekt Forretningssiden It chef Input Samtlige aftaler vedrørende it opsamles, både konkrete aftaler og rammeaftaler Output Output er: Y5.1 Kontraktforhold. Dette er en oversigt over aftaler der kan påvirke udviklingen og implementeringen af en ny enterprise arkitektur Metode Man indsamler de eksisterende aftaler, og opsamler for hver af dem essensen af aftalen. Denne oversigt bør omfatte: Aftalepartner hvem har man indgået aftalen med? Aftaleperiode i hvilken periode gælder aftalen, og hvordan kan den opsiges? Økonomiske forhold hvilke udgifter/indtægter reguleres af aftalen? Væsentlige aftaleparametre såsom forpligtelser partnerne imellem, serviceniveauer, osv. Eventuelle bemærkninger er aftalen fordelagtig eller ej; ønsker man den ideelt set erstattet af noget andet? Det er uhyre relevant også at få beskrevet sammenhænge mellem forskellige aftaler! Eksempelvis vil et licenseret økonomisystem ofte basere sig på en database og et operativsystem der er licenseret fra andre leverandører, og man kan derfor ikke blot ændre i én aftale uden at tage højde for de bindinger der er til andre aftaler. Bindingen kan for eksempel være sådan at man forpligter sig til løbende at opgradere sin database og operativsystem, før supportaftalen med økonomisystemet gælder. De aftaler der kan være relevante at opsamle, omfatter: Driftsaftaler. Disse dækker aftaler mellem to eller flere parter med hensyn til driftskapacitet, support og konsulentydelser mv. Licensaftaler. Disse omfatter typisk support- og opgraderingsomkostninger til operativsystemer, database-systemer, ERP-systemer og andre løsninger. Se også bemærkning i gode råd. Leverandøraftaler. Disse dækker kontrakter mellem rekvirent og leverandør vedr. leverance af ydelser og/eller systemer. Dette kan omfatte SKI-aftaler, hvor et antal leverandører er udvalgt indenfor forskellige leverancekategorier, og timepriser allerede aftalt. Kontraktudkast dækker forslag til kontrakt og udkast til kontraktbilag mellem myndighed/virksomhed og it-leverandør. Der kan for eksempel være tale om aftaler under SKI, hvor kontrakterne er fastlagte, bortset fra de bilag der specificerer den konkrete ydelse. OIO EA trinbeskrivelser v1.0 Side 70 af 71 Februar 2007

71 SLA-aftaler (Service Level Agreement) dækker aftaler mellem en aktør (intern eller ekstern), som leverer en it-ydelse og en bruger/forretningsenhed som anvender ydelserne. Web-serviceaftale. Disse dækker aftaler mellem serviceudbyder og servicekonsument om tilvejebringelse af web-service baseret snitflade i Service Orienteret Arkitektur (SOA). De beskrives via en WSDL. Udbudsannoncer. Disse dækker udbudsannoncer, jfr. EU's udbudsdirektiv. Anskaffelsesprocesser. Disse dækker beskrivelser af processer som har til formål at anskaffe et itsystem (fx EU udbudsproces). Der vil i disse være kontraktmæssige bindinger til hvordan et sådant anskaffelsesforløb skal ske. Fler-parts aftaler. Disse dækker aftaler mellem to eller flere, som stiller web-services og andre itgrænseflader til rådighed for hinanden som system-system snitflader eller som brugergrænseflader Gode råd Man bør udvikle enterprise arkitekturen (i trinene A5 frem til C4) uafhængigt af eksisterende aftaler. I D. Gap analysen, ikke mindst i D1. Restriktioner, kan man så tage højde for de eksisterende aftaler, således at en migreringsplan (trin E2) også tilgodeser disse (eksempelvis at aftaler udløber på givne tidspunkter, og med fordel kan erstattes af andre). Open source software er de senere år blevet meget relevant i mange sammenhænge. Man bør dog være opmærksom på at open source også har nogle kontraktuelle licens-forpligtelser. Nogle open source licenser for eksempel GPL (GNU General Public License) stiller krav om at man offentliggør de ændringer til kildekoden man har foretaget. Hvis man integrerer open source med et proprietært system, kan dette indebære at dele af det proprietære systems kildekode også skal offentliggøres, hvilket man nok ikke har rettighederne til. Så man bør undersøge disse forhold, og sikrer sig at man ikke påtager forpligtelser man ikke ønsker. Man bør generelt sikre sig så meget ejerskab over kildekode som muligt. It-leverandører af integrationer mellem systemer bør så vidt muligt give ejerskabet af kildekoden til integrationerne videre, således at man selv fremover kan vedligeholde integrationen Eksempler Der er på nuværende tidspunkt ingen eksempler. OIO EA trinbeskrivelser v1.0 Side 71 af 71 Februar 2007