OIO Enterprise Arkitektur. Michael Bang Kjeldgaard Lars Wilkens Henriksen Jens Peter Koch / Emil Broholm

Størrelse: px
Starte visningen fra side:

Download "OIO Enterprise Arkitektur. Michael Bang Kjeldgaard Lars Wilkens Henriksen Jens Peter Koch / Emil Broholm"

Transkript

1 OIO Enterprise Arkitektur Aalborg 29. oktober 2007 Århus 30. oktober 2007 København 5. november 2007 Odense 5. november 2007 Michael Bang Kjeldgaard Lars Wilkens Henriksen Jens Peter Koch / Emil Broholm

2 Agenda

3 Introduktion fortæl ganske kort Kender og bruger i Enterprise Arkitektur metoder? Forventninger til i dag?

4 De fire væsentligste punkter i dag OIO EA trin og deres sammenhænge De røde tråde i OIO EA EA governance Hvordan kommer I godt i gang? Borger Indgiv ansøgning Modtag udbetaling Trin Beskrivelse Aktører Services O bjekter 1. Borger klikker på sagsoversigt i Borgerportalmenu. Borger Kunde.HentKundeSt amdata( Kunde_ID) Borger 2. Borger t ilgår detaljerede oplysninger om de enkelte sager Borger Sag.Hent [Journalnummer] (Henter oplysninger om sagen) Borger Af slag Start Borgerportal Borgerportal Ansøgning Afslag Sagsbehandlingssystem Udbetaling Sagsbehandler Kontroller ans øgning for formalia Begrund og send afslag Gentoptag sagsbehandling Nej Nej Sagsbehandling Formalia overholdt? ja Ansøgning imødekommet? Ja Start udbetaling Nej Kontrol Kontrol Er udbetaling i Ja orden? Opret borgerkonto Systemadministrator Stop Henvendelse B4. Forretningsprocesser Borger-stamdata Be skrivelse Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. Input Borgerens identifikation Dato Borgerens stamdata Sag Hændelse Sag.Akt_List [Journalnummer] (Viser alle hændelser på sagen, som aktøren har adgang til at se) Output Sag.Akt_Hent [Journalnummer, Aktnummer] (Henter netop én hændelse og de oplysninger, der er knyttet til hændelsen) Økonomi Fo rretnings mæss ig se rvice Sag.Doku ment_list [Aktnummer] (Viser evt. dok umenter journaliseret på hændelsen) Fe jl Borgeren har ikke identificeret sig genkendeligt Dato er uden for intervallet Fo rretnings mæss ig SLA Brugeren (borgeren/sagsbehandleren ) skal have adgang t il de registrede informationer 24 timer i døgnet, bortset fra eventuelle system-nedetider, der maksimalt andrager 2 timer i intervallet per døgn. Borgeren have nem adgang til at indsende opdateringer t il oplysningerne. Borgeren skal kunne se sine informationer v ia en sikker, krypteret forbindelse. Note r UseCase refere nce Borgerportal Opret sag Inf ormer om at sag er oprettet CPR/CVR/BBR Borger Sagsbehandling Sagsbehandler Udbetaling Sagsbehandlings system Kontrol Økonomisystem B5. UseCases -detaljeret -beskrivelse UC 2.06 UC 2.07 UC 5.03 UC 5.07 UC 5.08 UC 5.15 kunde UC 9.80 Opret autorisation Anmod om autorisation Identificer kunde Opret CVR- kunde Opret CPR- kunde Behandl anmodning om oprettelse som Manuel godkendelse af ansøgning B3. Forrretningsservices Vis sagsf orløb Teknisk service Beskrivelse B5. UseCases Input Output Fejl Teknisk SLA Noter UseCase reference B1. Forretningsobjekter Service reference Hent_Borgerstamdata Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. KundeNøgle Dato (Date) KundeStamdata UkendtKunde UgyldigDato Svartid på maksimum 2 sekunder. Systemoppetid 99% i intervallet 6:00-22:00. Systemlukning for vedligeholdelse kan ske i intervallet 22:00-6:00, men højest 10 timer om måneden. Noter UC 2.06 Opret autorisation UC 2.07 Anmod om autorisation UC 5.03 Identificer kunde UC 5.07 Opret CVR- kunde UC 5.08 Opret CPR- kunde UC 5.15 Behandl anmodning om oprettelse som kunde UC 9.80 Manuel godkendelse af ansøgning Borger-stamdata C3. Servicearkitektur

5 Agenda

6 Hvad er enterprise arkitektur? Forretning Teknologi Broen imellem de to Skal altid være Forståelig Opdateret I brug => Behov for EA governance

7 Barrierer for digital forvaltning 2006 Kilde: Danmarks Statistik februar 2007

8 Hvidbogens strategiske kobling mellem forretning og teknologi

9 Roadmap for det fælles arkitekturarbejde ( Modenhed, sammenhæng, Effektivitet og nytteværdi FESD standarder 2 Digital signatur 2 Arkitekturkrav Adm. fællesskaber Kortlægning B 103 krav om standarder ISB2 integrationsmodel for portaler Domænebestyrelsers handlingsplaner Fælles løsning Brugerstyring SOA infrastruktur / OIOSI Softwarebørs Sektorstandardering OIO EA ramme / arkitekturguide DS 484 Brugerstyringsreferencemodel FESD, efaktura, NemKonto Håndbog om it-arkitektur Katalog over standarder Hvidbog om it-arkitektur edag1 + 2 Tid og gennemførte OCES / digital signatur arkitekturprojekter OIOXML & ISB Aftale om udveksling af data

10 OIO arkitekturmetodevejledning (2003) Modenhed, sammenhæng, Effektivitet og nytteværdi FESD standarder 2 Digital signatur 2 Arkitekturkrav Adm. fællesskaber Kortlægning B 103 krav om standarder ISB2 integrationsmodel for portaler Domænebestyrelsers handlingsplaner Fælles løsning Brugerstyring SOA infrastruktur / OIOSI Softwarebørs Sektorstandardering OIO EA ramme / arkitekturguide DS 484 Brugerstyringsreferencemodel FESD, efaktura, NemKonto Håndbog om it-arkitektur Katalog over standarder Hvidbog om it-arkitektur Tid og gennemførte arkitekturprojekter edag1 + 2 OCES / digital signatur OIOXML & ISB Aftale om udveksling af data

11 OIO arkitekturmetodevejledning (2003) Modenhed, sammenhæng, Effektivitet og nytteværdi FESD standarder 2 Digital signatur 2 Arkitekturkrav Adm. fællesskaber Kortlægning B 103 krav om standarder ISB2 integrationsmodel for portaler Domænebestyrelsers handlingsplaner Fælles løsning Brugerstyring SOA infrastruktur / OIOSI Softwarebørs Sektorstandardering OIO EA ramme / arkitekturguide DS 484 Brugerstyringsreferencemodel FESD, efaktura, NemKonto Håndbog om it-arkitektur Håndbog om it-arkitektur Katalog over standarder Hvidbog om it-arkitektur Tid og gennemførte arkitekturprojekter edag1 + 2 OCES / digital signatur OIOXML & ISB Aftale om udveksling af data

12 OIO arkitekturmetodevejledning (2003) Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends Strategi X2. Tekniske trends Forretning Teknik Modenhed, sammenhæng, Effektivitet og nytteværdi A1. EArelaterede udfordringer A3. EA metodegrundlag A2. EA governance strategi A4. Projekt charter A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring Gap analyse E1. Migrationsstrategi E2. Migrationsplan D1. Restriktioner E3. Konsekvensanalyse D3. Gap analyse D2. Muligheder FESD standarder 2 Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Digital signatur 2 Arkitekturkrav Adm. fællesskaber Kortlægning B 103 krav om standarder ISB2 integrationsmodel for portaler Domænebestyrelsers handlingsplaner Fælles løsning Brugerstyring SOA infrastruktur / OIOSI Softwarebørs Sektorstandardering OIO EA ramme / arkitekturguide OIO EA ramme / arkitekturguide DS 484 Brugerstyringsreferencemodel FESD, efaktura, NemKonto Håndbog om it-arkitektur Håndbog om it-arkitektur Katalog over standarder Hvidbog om it-arkitektur Tid og gennemførte arkitekturprojekter edag1 + 2 OCES / digital signatur OIOXML & ISB Aftale om udveksling af data

13 OIO arkitekturmetodevejledning (2008) Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Samordnet model der Modenhed, sammenhæng, overordnet kobler OIO EA Effektivitet og nytteværdi til forskellige metoder, fx FOKUS, DS 484, ITIL, Prince 2 Strategi A1. EArelaterede udfordringer A3. EA metodegrundlag A2. EA governance strategi A4. Projekt charter Forretning Teknik A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases C1. Informationsarkitektur C3. Servicearkitektur A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring Gap analyse E1. Migrationsstrategi E2. Migrationsplan D1. Restriktioner E3. Konsekvensanalyse D3. Gap analyse D2. Muligheder FESD standarder 2 Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Digital signatur 2 Arkitekturkrav Adm. fællesskaber Kortlægning B 103 krav om standarder ISB2 integrationsmodel for portaler Domænebestyrelsers handlingsplaner Fælles løsning Brugerstyring SOA infrastruktur / OIOSI Softwarebørs Sektorstandardering OIO EA ramme / arkitekturguide OIO EA ramme / arkitekturguide DS 484 Brugerstyringsreferencemodel FESD, efaktura, NemKonto Håndbog om it-arkitektur Håndbog om it-arkitektur Katalog over standarder Hvidbog om it-arkitektur Tid og gennemførte arkitekturprojekter edag1 + 2 OCES / digital signatur OIOXML & ISB Aftale om udveksling af data

14 Eksempler på brugere af OIO EA Københavns Kommune Odense Kommune Århus Kommune KL Danske Regioner / EPJ arkitektur KMS OIO-udvalget for socialområdet FESD 2 ISB 2 ITST.dk

15 Agenda

16 OIO Arkitekturramme elementer Arkitekturramme Enterprise arkitekturmetode EA Scenarier EA Rammeværk Kompetencer og roller Introduktion Trinbeskrivelser Profilværktøj Mapning til andre metoder Klassifikation/taksonomier Downloadable dokumenter Engelsk Introduktion FAQ Arkitekturbibliotek Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Information Applikation Teknologi Strategier Forretningsstrukturer Objektmodeller Applikationsarkitektur Teknologimodel Principper Processer Logiske datamodeller Forretningslogik Teknologistruktur Forretningsregler Workflows Fysiske datamodeller Applikationsdesign Teknologilandskab Trends og projektgrundlag Gap analyse Forandring Governance Styring Konceptuelt 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 Logisk Fysisk Forandring Gap analyse E1. Migrationsstrategi E2. Migrationsplan D1. Restriktioner E3. Konsekvensanalyse D3. Gap analyse D2. Muligheder Styringsrammer Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold

17 Overblik

18 OIO EA metoden

19 Metode trin for trin med eksempler og tips

20 Vigtige bemærkninger En løbende, iterativ proces at udvikle og vedligeholde en enterprise arkitektur OIO EA tilbyder en metode, et rammeværk, og en række andre hjælpemidler OIO EA kan bruges på et projekt, og på en projektportefølje OIO EA s trin ikke nye men giver en sammenhængende, velafprøvet tilgang De enkelte metodetrin udføres ikke i en fastlagt rækkefølge Man vil ofte udføre flere trin i parallel Indenfor hvert trin udarbejder man ikke altid alle leverancer Nogle gange laver man andre leverancer end de foreslåede Det er ikke et mål i sig selv at lave EA! EA arkitekten er gennemgående i alle trin

21 Brug af OIO EA metoden Fuld EA Delvis EA IT-projekt Konsolidering af arbejdsgange ved fusion Konsolidering af koncern infrastruktur Koncern informations -arkitektur IT-udbud Datainfrastruktur for sektor Fællesoffentlig infrastruktur

22 OIO EA scenarier

23 EA scenarie: Dir. For Fødevareerhverv (DFFE) Fødevaresektor begrebsmodel DFFE krav Strategi Forretning A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier A2. EA governance strategi A4. Projekt charter A6. It-principper Begrebsmodel B1. Forretningsobjekter Services B3. Forretningsservices B2. Lokationer/ organisation B4. Forretningsprocesser Teknik B5. UseCases C3. Servicearkitektur B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan Operationer Domænemodel C1. Informationsarkitektur Gap analyse D1. Restriktioner E3. Konsekvensanalyse D3. Gap analyse DFFE term Grundlag for udbud D2. Muligheder Nuværende arkitektur Fremtidige arkitektur Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold

24 Gennemgående EA eksempel

25 OIO EA metode gennemgående eksempel Tekniske og Forretningsmæssige Trends X1. Lovmæssige bindinger X2. Forretningsaspekter X4. Eksterne principper og politikker X3. Interessentforhold Strategi X5. Kontrakt og aftaleforhold Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier B1. Forretningsobjekter B3. Forretningsservices B5. UseCases A2. EA governance strategi A4. Projekt charter A6. It-principper B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow Forandring C1. Nuværende it-arkitektur - Information - Applikation - Service - Teknologi Gap analyse E1. Migreringsstrategi E3. Konsekvensanalyse D1. Restriktioner E2. Migreringsplan E4. EA governance D2. Muligheder D3. Gap analyse Principper og Styring Y1. OIO EA metodeudvikling Y2. Driftssituation Y3. Budget- og resourcestyring C2. Informationsarkitektur C4. Servicearkitektur (fremtidig) (fremtidig) C3. Applikationsarkitektur C5. Teknologiarkitektur (fremtidig) (fremtidig)

26 EA scenarie: DFFE trintilpasning (forretningsprocesser)

27 EA scenarie: DFFE-specifikke skabeloner

28 Relation til andre metoder og rammeværk

29 OIO EA relateret til andre metoder & rammeværk Processer Begreber 1. Procesoverblik OIO EA er en fuld EA metode der mapper til andre metoder og rammeværk Guiden indeholder mapninger til B4. Forretningsprocesser 2. Generelle processer B6. Workflow B1. Forretningsobjekter 2. Centrale begreber 3. Processer TOGAF FEAF Zachman Figuren viser hvordan SKATs arkitekturmetode trin relaterer sig til OIO EA trinene Overbliks niveau 1. Domænegruppe B6. Workflow 3. Overordnet begrebsmodel 4. Aktiviteter Konkret niveau B5. UseCases C3. Servicearkitektur C1. (vigtigste egenskaber) Informationsarkitektur 4. Detaljeret begrebsmodel 5. Services B3. Forretningsservices B1. Forretningsobjekter C1. Informationsarkitektur 5. Udsnit af begrebsmodel C1. Informationsarkitektur

30 OIO EA roller

31 Enterprise arkitektprofil

32 OIO EA kompetencer og profiler Værktøj til vurdering af arkitekturkompetencer og sammensætning af teams

33 OIO EA rammeværk og klassifikation

34

35 OIO arkitekturrammeværk en bogreol Strategi Forretning Information Applikation Teknologi Strategier Forretningsstrukturer Objektmodeller Applikationsarkitektur Teknologimodel Principper Processer Logiske datamodeller Forretningslogik Teknologistruktur Forretningsregler Workflows Fysiske datamodeller Applikationsdesign Teknologilandskab Trends og projektgrundlag Gap analyse Forandring Governance Styring Konceptuelt Logisk Fysisk Styringsrammer

36 OIO EA reol - hyldeindhold

37 OIO EA reol med dokumenter Konceptuelt Strategi Forretning Information Applikation Teknologi Strategier Forretningsstruktur Objektmodeller Applikationsstrategi Teknologistrategi A5.1 Vision, mål, strategier, KSFer A5.2 Metrikker, KPIer A5.3 SWOT, business drivers, 5 forces A5.5 Interessentanalyse Principper Logisk A6.1 It-principper, rationale, implikationer Forretningsregler Fysisk A5.4 Forretningsregler Trends og projektgrundlag Styringsrammer Andre Dokumenttyper Denne kategori indeholder dokumenter Der dækker mange af de ovenstående områder, samt mere X1.1 X2.1 A1.1 A3.1 A4.1 A4.2 Forretningsmæssige trends Tekniske trends EA-relaterede udfordringer OIO EA metode (tilpasset) Projekt charter Business case Foranalyse og it strategi Kan indeholde mange af leverancerne ovenfor A1.1 EA-relaterede udfordringer A6.1 it-principper, rationale, implikationer Lokationsmodel Organisationsmodel Aktørmodel Forretningsservices Forretningsservices-Lok. map Forretningsservices-Org. map Processer B4.1 B4.2 B4.3 B4.4 B4.5 Procesmodel Proces-evaluering Proces-forretningsobjekt map Proces-lokationsmap Proces-organisationsmap Workflows B6.1 Workflows B6.2 Forretningsregler tilknytttet workflows Gap analyse D1.1 Restriktioner, konsekvenser og alternativer D1.2 Risikoanalyse D2.1 Muligheder, vigtighed og indsats D3.1 Gap analyse Kravspecifikationer Kan indeholde mange af leverancerne ovenfor, samlet i et dokument B1.1 Forretningsobjekter B1.2 Forretningsobjekters relationer B1.3 Forretningsspørgsmål Logiske datamodeller C1.1 Informationsobjekter i LDM C1.2 Data Distribution C1.3 Database oversigt Fysiske datamodeller C1.4 Fysisk datamodel, incl. OIOXML Forandring E1.1 Migreringsstrategi E2.1 Migreringsplan E3.1 Konsekvensanalyse Projektledelse og - styring Kan indeholde mange af leverancerne ovenfor, samlet i et dokument, herunder A3.1 OIO EA metode (tilpasset) A4.1 EA projekt charter E1.1 Migreringsstrategi E2.1 Migreringsplan C2.3 Applikation infrastruktur mønstre C2.6 Integrationsstrategi/mønstre C4.1 Teknologi referencemodel Applikationsstruktur C2.1 C2.2 C2.4 C2.5 C2.7 B5.1 C3.1 Applikationkatalog Applikation-Information map Applikation-Proces map Integrationskatalog Applikation-Integration views Use Cases Serviceoversigt Teknologistruktur C4.2 ABB (Arkitektur ByggeBlokke) C4.3 System topologier C4.4 Udvidede system topologier Applikationsdesign C3.2 Komponentopdelt applikationslandskab C3.3 (Web)serviceforretningsservice map Teknologilandskab C4.5 Teknologi inventory Governance A2.1 EA governance strategi Y3.1 EA governance beskrivelse Implementering og test Indeholder dokumenter der ikke direkte er OIO EA-relaterede, men som alligevel kan være af interesse. Herunder: Designspecifikationer Testplaner Testdokumentation Styring Y1.1 Y2.1 Y4.1 Y5.1 Drift Budget og ressourcer Lovmæssige bindinger Kontraktforhold Sikkerhed Kan indeholde mange af leverancerne ovenfor, samlet i et dokument der specificerer komplekse sammenhænge,, herunder C4.4 Udvidede system topologier Sammenhængende kobling af metode og leverancer B2.1 B2.2 B2.3 B3.1 B3.2 B3.3

38 OIO EA reol med standarder

39 Dokumenter og andre ressourcer

40

41 FAQ fremhævede punkter Om EA & OIO EA Sammenhæng mellem OIO EA metode, ramme, mv. Om EA versus SOA EA er en metoderamme, SOA et arkitekturprincip (mønster) EA kan bruges til at udvikle SOA og andre arkitekturmønstre SOA udvikles bedst ved brug af EA Om brug af OIO EA Alle må gratis bruge OIO EA Leverandører må udvikle og tilbyde tjenester baseret på OIO EA, men kun tage sig betalt for deres valueadd IT- og Tele har ikke pt. en branding af OIO EA services Om vedligehold af OIO EA Alle kan bidrage med forslag og materiale Mindre ændringer indføres, større er under change control

42 Nyt i OIO EA arbejdsmodel Organisation Metode Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends Strategi X2. Tekniske trends 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 D1. Restriktioner E3. Konsekvensanalyse D3. Gap analyse D2. Muligheder Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Projekt Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Dokumentationsramme Konceptuelt Strategi Forretning Information Applikation Teknologi Strategier Forretningsstruktur Objektmodeller Applikationsstrategi Teknologistrategi A5.1 Vision, mål, strategier, KSFer A5.2 Metrikker, KPIer A5.3 SWOT, business drivers, 5 forces A5.5 Interessentanalyse B2.1 B2.2 B2.3 B3.1 B3.2 B3.3 Lokationsmodel Organisationsmodel Aktørmodel Forretningsservices Forretningsservices-Lok. map Forretningsservices-Org. map B4.1 B4.2 B4.3 B4.4 B4.5 Procesmodel Proces-evaluering Proces-forretningsobjekt map Proces-lokationsmap Proces-organisationsmap Principper Logisk A6.1 It-principper, rationale, implikationer Forretningsregler Fysisk A5.4 Forretningsregler Trends og projektgrundlag Styringsrammer X1.1 X2.1 A1.1 A3.1 A4.1 Forretningsmæssige trends Tekniske trends EA-relaterede udfordringer OIO EA metode (tilpasset) EA projekt charter Processer Workflows B6.1 Workflows B6.2 Forretningsregler tilknytttet workflows Gap analyse D1.1 Restriktioner, konsekvenser og alternativer D1.2 Risikoanalyse D2.1 Muligheder, vigtighed og indsats D3.1 Gap analyse B1.1 Forretningsobjekter B1.2 Forretningsobjekters relationer B1.3 Forretningsspørgsmål Logiske datamodeller C1.1 Informationsobjekter i LDM C1.2 Data Distribution C1.3 Database oversigt Fysiske datamodeller C1.4 Fysisk datamodel, incl. OIOXML Forandring E1.1 Migreringsstrategi E2.1 Migreringsplan E3.1 Konsekvensanalyse C2.3 Applikation infrastruktur mønstre C2.6 Integrationsstrategi/mønstre Applikationsstruktur C2.1 C2.2 C2.4 C2.5 C2.7 B5.1 C3.1 Applikationkatalog Applikation-Information map Applikation-Proces map Integrationskatalog Applikation-Integration views Use Cases Serviceoversigt Applikationsdesign C3.2 Komponentopdelt applikationslandskab C3.3 (Web)serviceforretningsservice map Governance A2.1 EA governance strategi Y3.1 EA governance beskrivelse C4.1 Teknologi referencemodel Teknologistruktur C4.2 ABB (Arkitektur ByggeBlokke) C4.3 System topologier C4.4 Udvidede system topologier Teknologilandskab C4.5 Teknologi inventory Styring Y1.1 Drift Y2.1 Budget og ressourcer Y4.1 Lovmæssige bindinger Y5.1 Kontraktforhold

43 Nyt i OIO EA Version 1.1 af OIO EA metode Business case tilføjet (A4.2) PRINCE2 stil Tekstuelle småkorrektioner Version 1.1 af OIO EA reol Tekstuelle småkorrektioner

44 Nyt i OIO EA Bedre gennemgående eksempel Eksempel og skabelon lægges op Business case tilføjet (A4.2) PRINCE2 stil Change control aktiveret # Change request 1 Business case Indfør business case som eksplicit leverance Stillet af LWH Dato Kategori Område Mellem A4 - A5 Estimat (timer) Anbefaling Rationale / løsning 2 Accepter Business cases bruges i flere projekter, og OIO EA vejledning (med referencer til andre dokumenter) herom vil være nyttigt. AK Konklusion n Accepteret Dato Status Udestår (Kun A5) Udestår Der indføres et trin/en leverance A4.2 Business case Business case nævnes måske i trin A5, men ikke som særskilt leverance. 2 A5 input A5 skal være input til trin B1 og B4, og brugen af prioriteringer forklares bedre. LWH Mellem B1, B4 4 Accepter A5 hælper til at prioritere n Åben 3 A4 EA. Projekt charter Ændres til "A4. Projekt charter" LWH/MBK Mellem A4 2 Accepter Betydningen gøres brederere; Projekt charter kan være for et helt EA projekt, eller for et enkelt projekt/sæt af projekter der bruger EA trin n Accepteret Trin ændres til A4. Projekt charter Leverance A4.1hedder du Projekt charter 4 Flere røde tråde LWH Bedre forklaring til de røde tråde - både på dokumentform og i præsentationer Stor A-B-C primært, men også D-E 30 Accepter Dette er den generelle forklaring af vigtigheden af at tænke disse flows ind, i trin A3. Konkret skal der peges på de links mellem leverancer der giver mest værdi (fx StrategiProcesser-Applikationer) n Åben Implementeret

45 Nyt i OIO EA den røde tråd i forretnings- og teknikmodelleringen (eks.: SOA tilgang) Borger Indgiv ansøgning Modtag udbetaling Trin Beskrivelse Aktører Services Objekter 1. Borger klikker på sagsoversigt i Borgerportalmenu. Borger Kunde.HentKundeSt amdata( Kunde_ID) Borger Borger tilgår detaljerede oplysninger om de enkelte sager Borger Sag.Hent [Journalnummer] (Henter oplysninger om sagen) Borger A fslag Start 2. Borgerportal Ansøgning Af slag Sagsbehandlings system Udbetaling Sagsbehandler Kontroller ansøgning f or formalia Borgerportal Begrund og send af slag Gentoptag sagsbehandling Nej Nej Sagsbehandling Formalia overholdt? ja Ansøgning imødekommet? Økonomi Start udbetaling Nej Kontrol Kontrol Er udbetaling i Ja orden? Opret borgerkonto Systemadministrator Stop Henvendelse B4. Forretningsprocesser Borger-stamdata Beskrive lse Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. Input Borgerens identifikation Dato Borgerens stamdata Sag Hændelse Sag.Akt_List [Journalnummer] (Viser alle hændelser på sagen, som aktøren har adgang til at se) Output Sag.Akt_Hent [Journalnummer, Aktnummer] (Henter netop én hændelse og de oplysninger, der er knyttet til hændelsen) Ja Forretningsmæssig service Sag.Doku ment_list [Aktnummer] (Viser evt. dokumenter journaliseret på hændelsen) Fe jl Borgeren har ikke identificeret sig genkendeligt Dato er uden for intervallet Forretningsmæssig SLA Brugeren (borgeren/sagsbehandleren ) skal have adgang til de registrede informationer 24 timer i døgnet, bortset fra eventuelle system-nedetider, der maksimalt andrager 2 timer i intervallet per døgn. Borgeren have nem adgang til at indsende opdateringer til oplysningerne. Borgeren skal kunne se sine informationer via en sikker, krypteret forbindelse. Noter UseCase refere nce Borgerportal Opret sag Informer om at sag er oprettet CPR/CVR/BBR Borger Sagsbehandling Sagsbehandler Udbetaling B5. UseCases -detaljeret -beskrivelse UC 2.06 UC 2.07 UC 5.03 UC 5.07 UC 5.08 UC 5.15 kunde UC 9.80 Opret autorisation Anmod om autorisation Identificer kunde Opret CVR- kunde Opret CPR- kunde Behandl anmodning om oprettelse som Manuel godkendelse af ansøgning B3. Forrretningsservices Sagsbehandlingssystem Kontrol Økonomisystem Vis sagsforløb Teknisk service Beskrivelse B5. UseCases Input Output Fejl Teknisk SLA Noter UseCase reference B1. Forretningsobjekter Service reference Hent_Borgerstamdata Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. KundeNøgle Dato (Date) KundeStamdata UkendtKunde UgyldigDato Svartid på maksimum 2 sekunder. Systemoppetid 99% i intervallet 6:00-22:00. Systemlukning for vedligeholdelse kan ske i intervallet 22:00-6:00, men højest 10 timer om måneden. Noter UC 2.06 Opret autorisation UC 2.07 Anmod om autorisation UC 5.03 Identificer kunde UC 5.07 Opret CVR- kunde UC 5.08 Opret CPR- kunde UC 5.15 Behandl anmodning om oprettelse som kunde UC 9.80 Manuel godkendelse af ansøgning Borger-stamdata C3. Servicearkitektur

46 Nyt i OIO EA kurser/seminarer En styrelse (1/10 30 deltagere, høj tilfredshed) ITST (5/10 20 deltagere, god tilfredshed) Leverandørseminar 24/10 (pt. 40 tilmeldte) Myndighedskurser 29/10, 30/10, 5/11, 8/11 (pt. ca. 100 tilmeldte) Planlagt: flere møder med udvalgte myndigheder

47 Agenda

48 Agenda

49 Bemærkninger til OIO EA OIO EA er en ramme tillempes altid behovet Man gør ikke alting Rækkefølgen er ikke fastlagt Man laver ikke alle leverancer Man genbruger Man laver også andre relevante leverancer Funderet på pragmatiske erfaringer og velafprøvet teori OIO EA kan bruges på en portefølje af projekter, og i enkelt projekt men der er best-practices fx to-be forretningsarkitektur før to-be teknikarkitektur Man søger at parallelisere Man har iterationer, hvor senere leverancer giver tilbageløb til tidligere 20-80% regel God ide med en gennemgående enterprise arkitekt Organisationens involvering fra start!

50 Generelt: Eksterne faktorer man kun i begrænset omfang kan påvirke, men som man frivilligt kan reagere på. Der identificeres hvilke forretningsmæssige tendenser der kan påvirke forretningen såsom nye ønsker fra borgere, virksomheder og andre interessenter. OIO EA metode Tekniske og forretningsmæssige trends Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Generelt: At følge trends, og tage initiativ til at de tænkes ind i Enterprise Arkitekturen, er en proaktiv indsats og adskiller en EA tilgang fra en reaktiv attitude til at bruge it i forretningen. Det er essentielt med en governance struktur, ledet af en enterprise arkitekt med god flair for både forretning og teknik. Der identificeres nye tekniske tendenser der åbner muligheder for at forretningen kan nå sine interessenter på nye måder.

51 Generelt: Primært interne faktorer, man i større grad er i kontrol over, men stadig under eksterne rammer. Trinet skal sikre at enterprise arkitekturen formidles og koordineres med den daglige drift således at driften kommer med sit input til arkitekturelle muligheder, og arbejder hen imod EA-målene OIO EA metode Principper og styring Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Y3. EA governance Trinet sikrer at foreslåede EA migreringsprojekter afstemmes med budgetter og ressourcer. Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold En oversigt og løbende styring på de lovmæssige bindinger der kan påvirke enterprise arkitekturen En styring af kontraktuelle forhold der skal tænkes ind i arkitekturen, og ikke mindst som enterprise arkitekturen skal søge at påvirke.

52 Nogle (forretning eller teknik) foreslår et EA-relateret initiativ, på baggrund af nogle udfordringer, der dokumenteres. EA-projektet defineres. Først tilpasses den generelle OIO EA metode til det konkrete behov, så kun relevante trin udføres, og kun de relevante leverancer produceres. Herefter defineres et klassisk projekt charter, med projektmål, aktivitets- og leveranceplan, ressourcer, business case, osv. OIO EA metode Strategi Strategi A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier A2. EA governance strategi A4. Projekt charter A6. It-principper Det sikres at der foreligger en governance strategi allerede inden projektstart, og at der er topledelsesopbakning til at sikre implementering af EA-arbejdets anbefalinger (ellers bliver det næppe en succes).

53 A1: EA-relaterede udfordringer Vores organisation er fragmenteret, der er ikke formuleret en fælles vision Silo-ledelse, ingen koordinering af it-indsatsen Ønsker fra forretningen og borgerne samles ikke sammen, og koordineres og prioriteres ikke Der er teknologiske muligheder for at levere en bedre service, men de bruges ikke Vi bruger meget tid på at udveksle informationer og koordinere med andre myndigheder Vi savner et overblik, så vi kan levere en bedre service Vi i it kan ikke rigtigt forklare hvorfor der er en business case i de it-investeringer vi foreslår Vi i forretningen kan ikke helt se hvordan vores budget til it bliver brugt så det hjælper os

54 A1. EA-relaterede udfordringer Formål Formål: at identificere de væsentligste udfordringer (problemer og muligheder) som organisationen står overfor, som en EA skal adressere Tværgående, komplekse, af væsentlig interesse Rationale: Et samlet overblik over væsentlige EA-relaterede udfordringer er et grundlag for at tilrettelægge EA-arbejdet således at disse adresseres Den business case der er i at udarbejde en EA og indføre EA governance, er i høj grad baseret på vigtigheden af at udfordringerne adresseres

55 A1. EA-relaterede udfordringer Indhold EA-relateret údfordring # Kategori Rub. Beskrivelse Interessent Konsekvens Vægt Et problem der skal løses, eller en mulighed der skal udnyttes, og som i sin natur er tværgående og komplekst, og dermed en det af enterprise arkitektur-området. Nummerering af den pågældende udfordring Kan være "problem" eller "mulighed". Rubricering - en underkategoriserin, beregnet til gruppere beslægtede udfordringer. En beskrivelse af udfordringen. Gerne med en kort navngivning af udfordringen. Se eksempel nedenfor. Den eller de gruppe mennesker der berøres af problemet/vil kunne få gavn af muligheden. En kvantitativ og kvalitativ indikation af hvad det vil give af fordele/gevinster at løse problemet/udnytte muligheden. Rubrikken kan også angive de risici der er ved ikke at adressere udfordringen. En indikation af hvor vigtigt det er at adressere udfordringen. Man kan bruge en skala 1-7, hvor 7 vægter mest, 1 mindst.

56 A1. EA-relaterede udfordringer Eksempel Eksempel # Kategori 1 Problem Rub. F-G 2 Mulighed F-IA 3 Mulighed T-AT 4 Problem F-G 5 Problem F-G Beskrivelse Interessent Manglende styring. Alle Manglende fælles overblik og styring, ITU ikke altid inddraget i tide. Konsekvens Vægt Usammenhængende og 6 inkonsistente beslutninger om itprojekter. En bedre koordination kunne spare 10% af it-udgifterne om 3 år. Borgervendt serviceansigt Borgere Borger får større indsigt i sin 5 situation, og adgang til denne Integreret udstilling af alle de informationer Sagsbehandlere 24x7. samlet har om borgeren Kommunen sparer noget ekspeditionstid. Mobil arbejdsplads. Mobile medarbejdere Bedre service 4 (hjemmehjælp, vej, ) Bedre datakvalitet Udstyre mobile medarbejdere med Sparede dobbeltindtastninger håndholdte enheder, med mobil adgang til Borgere fagapplikationer. Svag topledelsesforankring. Alle Arkitekturbeslutninger 6 realiseres ikke, med Svag forankring af arkitekturarbejde i inkonsistens og dobbeltarbejde topledelsen. til følge. Intet fælles sprog Alle Et fælles sprog vil fjerne 3 usikkerhed i kommunikationen Mangler fælles sprog for arkitekturtermer. mellem de involverede, og sikre at arkitekturarbejdes formidles konsistent.

57 A3: EA metodegrundlag OIO EA arbejdsmodel Organisation Metode Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends Strategi X2. Tekniske trends 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 D1. Restriktioner E3. Konsekvensanalyse D3. Gap analyse D2. Muligheder Principper og styring Y1. Driftssituation Y2. Budget- og ressourcestyring Projekt Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Dokumentationsramme Konceptuelt Strategi Forretning Information Applikation Teknologi Strategier Forretningsstruktur Objektmodeller Applikationsstrategi Teknologistrategi A5.1 Vision, mål, strategier, KSFer A5.2 Metrikker, KPIer A5.3 SWOT, business drivers, 5 forces A5.5 Interessentanalyse B2.1 B2.2 B2.3 B3.1 B3.2 B3.3 Lokationsmodel Organisationsmodel Aktørmodel Forretningsservices Forretningsservices-Lok. map Forretningsservices-Org. map B4.1 B4.2 B4.3 B4.4 B4.5 Procesmodel Proces-evaluering Proces-forretningsobjekt map Proces-lokationsmap Proces-organisationsmap Principper Logisk A6.1 It-principper, rationale, implikationer Forretningsregler Fysisk A5.4 Forretningsregler Trends og projektgrundlag Styringsrammer X1.1 X2.1 A1.1 A3.1 A4.1 Forretningsmæssige trends Tekniske trends EA-relaterede udfordringer OIO EA metode (tilpasset) EA projekt charter Processer Workflows B6.1 Workflows B6.2 Forretningsregler tilknytttet workflows Gap analyse D1.1 Restriktioner, konsekvenser og alternativer D1.2 Risikoanalyse D2.1 Muligheder, vigtighed og indsats D3.1 Gap analyse B1.1 Forretningsobjekter B1.2 Forretningsobjekters relationer B1.3 Forretningsspørgsmål Logiske datamodeller C1.1 Informationsobjekter i LDM C1.2 Data Distribution C1.3 Database oversigt Fysiske datamodeller C1.4 Fysisk datamodel, incl. OIOXML Forandring E1.1 Migreringsstrategi E2.1 Migreringsplan E3.1 Konsekvensanalyse C2.3 Applikation infrastruktur mønstre C2.6 Integrationsstrategi/mønstre Applikationsstruktur C2.1 C2.2 C2.4 C2.5 C2.7 B5.1 C3.1 Applikationkatalog Applikation-Information map Applikation-Proces map Integrationskatalog Applikation-Integration views Use Cases Serviceoversigt Applikationsdesign C3.2 Komponentopdelt applikationslandskab C3.3 (Web)serviceforretningsservice map Governance A2.1 EA governance strategi Y3.1 EA governance beskrivelse C4.1 Teknologi referencemodel Teknologistruktur C4.2 ABB (Arkitektur ByggeBlokke) C4.3 System topologier C4.4 Udvidede system topologier Teknologilandskab C4.5 Teknologi inventory Styring Y1.1 Drift Y2.1 Budget og ressourcer Y4.1 Lovmæssige bindinger Y5.1 Kontraktforhold

58 A3: EA metodegrundlag DFFE Organisation Metode Fødevaresektor begrebsmodel DFFE krav Strategi Forretning A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier A2. EA governance strategi A4. Projekt charter A6. It-principper Begrebsmodel B1. Forretningsobjekter Services B3. Forretningsservices B2. Lokationer/ organisation B4. Forretningsprocesser Teknik Domænemodel C1. Informationsarkitektur C3. Servicearkitektur B6. Workflow C2. Applikationsarkitektur C4. Teknologiarkitektur Forandring E1. Migreringsstrategi E2. Migreringsplan Operationer B5. UseCases Gap analyse D1. Restriktioner E3. Konsekvensanalyse D3. Gap analyse DFFE term Grundlag for udbud D2. Muligheder Nuværende arkitektur Fremtidige arkitektur Principper og styring Y1. Driftssituation Projekt Y2. Budget- og ressourcestyring Y3. EA governance Y4. Lovmæssige bindinger Y5. Kontrakt og aftaleforhold Dokumentationsramme

59 A4. Projekt charter A4.1 Projekt charter Projekt charter kan være for En generel EA aktivitet Et specifikt projekt der benytter EA trin Projektplan på basis af tilpasset OIO EA metode Aktiviteter Leverancer Roller og ansvarlige Kan i PRINCE2 termer være: Projektgrundlag Project Initiation Document (PID)

60 A4. Projekt charter A4.2 Business case En business case for EA kan omfatte (PRINCE2): Årsag Muligheder Udbytter Risici Omkostninger og tidsplan Investeringsvurdering Business case kan blive formuleret på baggrund af EA-relaterede udfordringer Business Case skal vedligeholdes Er der ikke længere en business case, skal projektet stoppes

61 Agenda

62 OIO EA metode Strategi Strategi A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier A2. EA governance strategi A4. Projekt charter A6. It-principper Det egentlige projekt begyndes med at dokumentere forretningens vision, mål, strategier osv. Disse prioriteres, og tjener som retningslinier for det videre arbejde. NB: EA projektet udvikler ikke strategier og mål det konsoliderer blot hvad forretningen samlet set ønsker. Organisationens it-principper dokumenteres, som beslutningsgrundlag senere. Dette er en blanding af at dokumentere hvad der måtte eksistere, og at definere hvad der måtte mangle.

63 A5.1 Vision, mål og strategier Vis ion Må l Str ate gie r Kri tisk e suc (KS cesfa Fer k to ) r er

64 Trin A.5 Vision, mål og strategier Flere mulige leverancetyper A5.1 Vision, mål, strategier samt 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. A5.4 Forretningsregler mere detaljerede, operationelle regler for forretningens virke. A5.5 Interessentanalyse - hvilke væsentlige spillere har hvilke interesser? NB: Dette er ikke management consulting forretningsstrategielementer konsolideres og dokumenteres men nyudvikles ikke

65 Vis ion Må l S tr A5.1 Vision, mål og strategier - Vision En høj-niveau hensigtserklæring om hvad organisationens virke egentlig skal udrette ate gie r Kri tisk e suc (K S cesfa Fer k to ) r Danmarks mest velfungerende digitale kommunale forvaltning er

66 Vis ion Må l S tr A5.1 Vision, mål og strategier - Mål Højniveau mål for organisationen typisk 3-5 år ude i fremtiden Skal kunne måles Typisk 3-4 mål ikke for mange Penge, tid Medarbejdere borgere kunder Kvalitet ate gie r Kri tisk e suc (K S cesfa Fer k to ) r I 2010 skal der være: 15% besparelse i ressourcer brugt i kommunens sagsbehandling. 20% større tilfredshed med kommunens services, målt i tilfredsstillelsesmålinger blandt borgerne. 20% større tilfredshed med jobbet blandt kommunens sagsbehandlende medarbejdere. er

67 Vis ion Må l S tr A5.1 Vision, mål og strategier - Strategi En tilgang til at realisere sine mål Har typisk en horisont på 1-3 år ate gie r Kri tisk e suc (K S cesfa Fer k to ) r er

68 Vis ion Må l S tr A5.1 Vision, mål og strategier - Strategi OIOKs services skal gøres nemt tilgængelige for borgerne, også udenfor normale åbningstider Den enkelte borger skal have en nem oversigt over de sager der er, og har været, mellem borgeren og kommunen ate gie r Kri tisk e suc (K S cesfa Fer k to ) r er Kommunens medarbejdere skal have en nem og integreret adgang til alle relevante informationer i sagsbehandlingen af den enkelte borger Alle projekter skal underlægges enterprise arkitektur governance

69 Vis ion Må l S tr A5.1 Vision, mål og strategier - Kritisk succesfaktor (KSF) En KSF er en evne eller tilstand som hvis den er tilstede øger chancen for at man lykkes med sine strategier og dermed når sine mål KSFer bør prioriteres efter hvor vigtigt deres tilstedeværelse er for at strategierne lykkes 100% = Den bedst tænkelige, mulige situation Den aktuelle situation ate gie r Kri tisk e suc (K S cesfa Fer k to ) r er Vurder: Effekten for opnåelse af mål hvis dette gap lukkes?

70 Vis ion Må l S tr A5.1 Vision, mål og strategier - Kritisk succesfaktor (KSF) KSF-1: Forretningssiden er involverede og tager ejerskab (7). KSF-2: En samlet oversigt over borgerens engagement med kommunen (6). KSF-3: Sikkerhed, digital signatur (4). KSF-4: Registerloven overholdes (7). KSF-5: Der etableres en digital borgerportal (6). ate gie r Kri tisk e suc (K S cesfa Fer k to ) r KSF-6: Der etableres en digital sagsbehandlermedarbejderportal (6). KSF-7: Målinger gennemføres (5). KSF-8: Der er en klar skelnen mellem hvilke services kommunen udbyder, og hvilke der kan hentes gennem andre, allerede eksisterende offentlige services (3). KSF-9: Der bruges OIOdatastandarder (OIOXML) (4). KSF-10: Der er en integrationsbus, så andre myndigheder kan koble sig på (3). er

71 A5.3 SWOT-analyse Strengths Weaknesses Opportunities Threats

72 Strengths - Højt it-niveau blandt borgerne i Danmark - Stor udbredelse af bredbånd Opportunities - Større grad af sagsbehandlig flyttes over til borgerne - Hurtigere sagsbehandlingstid ved bedre integrerede systemer Weaknesses - Lille kendskab til OIOdatastandarder - Digital signatur ikke ret udbredt Threats - En restgruppe af borgere vil ikke være i stand til at selvsagsbehandle og vil måske helt opgive at få deres sag behandlet - Sikkerhedsaspekter

73 A6. It-principper Et it-princip: Udsiger noget fundamentalt om organisationens it-brug. Kan modsiges Er udtrykt i ikke-teknisk sprog Samlet ca principper, om: Information Applikation/services Teknologi Tværgående for eksempel sikkerhed Et princip skal kunne bruges til at træffe meningsfulde beslutninger Vi skal have brugervenlige systemer er ikke et princip man vil ikke argumentere for det modsatte Vi udvikler alt selv er et princip man vil kunne argumentere for det modsatte

74 A6. It-principper dokumentation It-princip: <Tekst der kortfattet udtrykker princippet> Rationale It-princip: <Kort begrundelse for princippet> Rationale Konsekvenser <Uddybende bemærkninger om vigtige konsekvenser af princippet> Alt data er som udgangspunkt tilgængelig for alle Jo bedre informerede medarbejderne er, jo bedre beslutninger tager de Konsekvenser Det skal sikres at registerloven overholdes Medarbejderne skal instrueres godt i hvilke politikker der er for omgang med data

75 Agenda

76 Generelt: I al fald TO-BE situation, undertiden også AS-IS. Forretningssiden dokumenterer hvilke essentielle objekter (begreber) og relationer imellem disse, der indgår i forretningen. Forretningen defineres mere operationelt, i form af processer der udføres, og services der leveres til interessenter. Disse relateres ofte til hvilke forretningsobjekter de benytter, og/eller hvilke lokationer de udføres/leveres fra. Der foretages en prioritering af processers/ services vigtighed, i forhold til strategierne. OIO EA metode Forretning Forretning B1. Forretningsobjekter B3. Forretningsservices B5. UseCases B2. Lokationer/ organisation B4. Forretningsprocesser B6. Workflow Forretningen specificerer sin struktur, i form af en eller flere af disse: -lokationer (logiske steder) -organisation (ansvarsmæssige strukturer) -aktører (roller) De opgaver forretningen organisationen løser, kan specificeres i UseCases, der siger hvad der udføres, men ikke detaljeret hvordan. UseCases relateres ofte til hvilke services de betjener sig af/leverer, hvilke forretningsobjekter de bruger, hvilke aktører der udfører dem, osv. Vigtige, komplekse processer og UseCases detaljeres til workflows, hvor man mere detaljeret beskriver hvordan der arbejdes.

77 B1. Forretningsobjekter Hvad er et forretningsobjekt? Noget der bruges i forretningen, af folk der ikke nødvendigvis har it-kendskab Borger, Sag, Henvendelse, Udbetaling Noget der bringes videre til implementering, i den mere tekniske modellering

78 B1. Forretningsobjekter modellering Identificér forretningsobjekter Navngiv dem Beskriv dem semantisk Identificér relationer mellem disse Identificér væsentlige attributter for de enkelte objekter

79 B1. Forretningsobjekter

80 B1. Forretningsobjekter

81 B2. Lokationer/organisation 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 og 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

82 B2. Lokationer/organisation 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.

83 B2. Lokationer/organisation

84 B2. Lokationer/ organisation

85 B3. Forretningsservices Udtrykt i et sprog forretningen forstår Leder frem til en service-orienteret arkitektur

86 B3. Den enkelte service: en kontrakt mellem servicemodtager og serviceudbyder Forretningsmæssigt niveau: mellem Kunde slutbruger og forretningsserviceleverandør: Service Forretningsservices Tekniske niveau: mellem forretningsserviceleverandør og teknisk leverandør SLA for Forretnings services Service Forretningsservices Teknisk Servicearkitektur SLA for Tekniske services

87 B3. Hvad er SOA? Forretningsmæssig synsvinkel Forretningsrelaterede services ikke teknologi! Services er kontraktbaserede Fokus på gevinst: Agilitet : hurtig reaktion på en ny situation ændrede lovkrav, ny markedssituation, nye produkter, Genbrugelighed den samme service skal kunne bruges i flere løsninger Leverandøruafhængighed man kan vælge den bedste leverandør af en given service (BBR, kreditrating, valutakurs, )

88 C3. Hvad er SOA? Teknisk synsvinkel SOA er et arkitekturprincip (et mønster) Services er genbrugelige, kan sammensættes Services er løst koblede Services er lokations-uafhængige Services er platformsuafhængige Fokus på interoperabilitet (nem integration integrationsbus) Brug af åbne standarder for data og teknologi Specifikation og implementering af en service er adskilte Services er kontraktbaserede Service-view på hvad it skal levere til forretningen Services kan leveres fra mange leverandører Services kan styres Tættere koblet til drift til forskel fra en monolitisk applikation kan det nemmere (via SLAs) identificeres hvilken service der fejler Vision: services registreres og kan opdages og bruges Vision: selv-helende services er den ikke tilgængelig fra en udbyder, er der andre

89 Forretningsmæssig service Borger-stamdata Beskrivelse Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. B3. Forretningsservices Input Output Borgerens identifikation Dato Borgerens stamdata Fejl Borgeren har ikke identificeret sig genkendeligt Dato er uden for intervallet Forretningsmæssig SLA Brugeren (borgeren/sagsbehandleren ) skal have adgang til de registrede informationer 24 timer i døgnet, bortset fra eventuelle system-nedetider, der maksimalt andrager 2 timer i intervallet per døgn. Borgeren have nem adgang til at indsende opdateringer til oplysningerne. Borgeren skal kunne se sine informationer via en sikker, krypteret forbindelse. Noter UseCase reference UC 2.06 UC 2.07 UC 5.03 UC 5.07 UC 5.08 UC 5.15 kunde UC 9.80 Opret autorisation Anmod om autorisation Identificer kunde Opret CVR- kunde Opret CPR- kunde Behandl anmodning om oprettelse som Manuel godkendelse af ansøgning

90 B3. Eksempel: Kunde Kunde

91 B3/C3. Kunde -servicen som eksempel UseCases UC 5.47 Generer udtræk af kundedatabase til ESDH ESDH UC 5.43 Automatisk opdatering af kunde Timer GLR UC 5.15 Behandl anmodning om oprettelse som kunde UC 5.08 Opret CPR- kunde «include» «include» UC 5.42 Opret kunde «include» «include» Sagsbehandler «include» CPR UC 5.07 Opret CVR- kunde «include» «include» CVR Kunde «Kundeservice» Autorisationselement Refererer til 0..* «Sag service» +modtagerstatus +udstederstatus +startdato +slutdato +autorisationniveau [0..1 no] +fuldautorisationtype [0..1 no] «Skemaservice» «metaclass row» indgår i 0..1 Ansøgning Sag +AnsøgningsID Forretningsservice +Sagsnummer 0..* Indsender 0..* 0..* Opret Kunde Opdater kunde automatisk Opdater kunde manuelt Beskriver 1 «Kundeservice» Kunde 1 +KundeID 0..* Ejer «Kundeservice» Areal Har 0..* «Kundeservice» Besætning «Kundeservice» Produktionsapparat 0..* 1 «Kundeservice» 1 1 «Kundeservice» Kommer fra Fartøj Produktion 0..* * Foretages i ft Teknologiservice Har udstedt 0..* relaterer til * Har modtaget Har 0..* «Kundeservice» 1 Kundeskifte Base Kunde.Opret Kunde.Stamdata_Hent Kunde.Stamdata_Ret Kunde Produktionsapparat Autorisationer og f uldmagter ServiceA gent Kundeskif te Metadata

92 B4. Forretningsprocesser Formål: Modellere processer Vigtigt at have, for at kunne relatere objekter og systemer til dem Fremtid: procesoptimering Anbefaling as-is : BPMN (15-30 processer) to-be : BPMN Begrundelse: BPMN ser ud til at blive accepteret proces modelleringsstandard Støtte fra de fleste leverandører

93 B4. Forretningsprocesser Borger Indgiv ansøgning Modtag udbetaling Afslag Start Ansøgning Afslag Udbetaling Sagsbehandler Kontroller ansøgning for formalia Begrund og send afslag Gentoptag sagsbehandling Nej Nej Sagsbehandling Formalia overholdt? ja Ansøgning imødekommet? Ja Økonomi Start udbetaling Nej Kontrol Kontrol Er udbetaling i Ja orden? Stop

94 B4. BPMN kan eksekveres BPD mapper ind i eksekverbare, XML-baserede sprog, såsom: BPEL (BPEL4WS - Business Process Execution Language for Web Services) Business Process Modelling Language (BPML) Support for BPMN i flere middleware produkter (BizTalk, Websphere, Oracle Applications, ) via BPEL

95 B5. Use cases Use cases beskriver hvad hvilke opgaver løses i samarbejde mellem hvem? Use cases beskriver ikke i videre detalje hvordan opgaverne løses Use cases definerer hvordan forretningen ser opgaverne, og er en start til at designe den it-støtte der skal understøtte arbejdet

96 B5. Use cases elementer Aktører roller: Mennesker og systemer Oversigtsdiagram: UseCases: opgaver der skal løses i samarbejde mellem aktørerne Opret borgerkonto Systemadministrator Aktør1 Henvendelse System1 Borgerportal Borger

97 B5. Use cases beskrivelse

98 Opret borgerkonto Systemadministrator Henvendelse B5. Use cases Borgerportal Opret sag Informer om at sag er oprettet CPR/CVR/BBR Borger Sagsbehandling Sagsbehandler Udbetaling Sagsbehandlingssystem Kontrol Økonomisystem Vis sagsforløb

99 B5. Use cases overordnet beskrivelse Use Case navn Version Dato Beskrivelse/formål Vis sagsforløb maj 2007 Formå let er at finde og vise en borgeren sin stamdata og engagementsoversigt af sager, hændelser og dokumenter Aktører Borger Borgerportal Sagsbehandlingssystem Startbetingelser Slutbetingelser Forretningsregler Borgeren er logget ind på kundeportalen. Stamdata samt liste over sager mv. v ises, med mu lighed for at gå videre t il en række skærmb illeder med me re detaljerede oplysninger. Kun borgere registreret som boende i ko mmunen kan logge ind. Normalt flow Alternativt flow Se nedenfor Ingen Kommentarer Ingen

100 B5. Use cases - detaljeret Trin Beskrivelse Aktører Services Objekter 1. Borger klikker på sagsoversigt i Borgerportalmenu. Borger Kunde.HentKundeSt amdata( Kunde_ID) Borger Borger t ilgår detaljerede oplysninger om de enkelte sager Borger Sag.Hent [Journalnummer] (Henter oplysninger om sagen) Borger 2. Borgerportal Borgerportal Sagsbehandlingssystem Sag Hændelse Sag.Akt_List [Journalnummer] (Viser alle hændelser på sagen, som aktøren har adgang til at se) Sag.Akt_Hent [Journalnummer, Aktnummer] (Henter netop én hændelse og de oplysninger, der er knyttet til hændelsen) Sag.Doku ment_list [Aktnummer] (Viser evt. dokumenter journaliseret på hændelsen)

101 En rød tråd i forretnings- og teknikmodelleringen (eks.: SOA tilgang) Borger Indgiv ansøgning Modtag udbetaling Trin Beskrivelse Aktører Services Objekter 1. Borger klikker på sagsoversigt i Borgerportalmenu. Borger Kunde.HentKundeSt amdata( Kunde_ID) Borger Borger tilgår detaljerede oplysninger om de enkelte sager Borger Sag.Hent [Journalnummer] (Henter oplysninger om sagen) Borger A fslag Start 2. Borgerportal Ansøgning Af slag Sagsbehandlings system Udbetaling Sagsbehandler Kontroller ansøgning f or formalia Borgerportal Begrund og send af slag Gentoptag sagsbehandling Nej Nej Sagsbehandling Formalia overholdt? ja Ansøgning imødekommet? Økonomi Start udbetaling Nej Kontrol Kontrol Er udbetaling i Ja orden? Opret borgerkonto Systemadministrator Stop Henvendelse B4. Forretningsprocesser Borger-stamdata Beskrive lse Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. Input Borgerens identifikation Dato Borgerens stamdata Sag Hændelse Sag.Akt_List [Journalnummer] (Viser alle hændelser på sagen, som aktøren har adgang til at se) Output Sag.Akt_Hent [Journalnummer, Aktnummer] (Henter netop én hændelse og de oplysninger, der er knyttet til hændelsen) Ja Forretningsmæssig service Sag.Doku ment_list [Aktnummer] (Viser evt. dokumenter journaliseret på hændelsen) Fe jl Borgeren har ikke identificeret sig genkendeligt Dato er uden for intervallet Forretningsmæssig SLA Brugeren (borgeren/sagsbehandleren ) skal have adgang til de registrede informationer 24 timer i døgnet, bortset fra eventuelle system-nedetider, der maksimalt andrager 2 timer i intervallet per døgn. Borgeren have nem adgang til at indsende opdateringer til oplysningerne. Borgeren skal kunne se sine informationer via en sikker, krypteret forbindelse. Noter UseCase refere nce Borgerportal Opret sag Informer om at sag er oprettet CPR/CVR/BBR Borger Sagsbehandling Sagsbehandler Udbetaling B5. UseCases -detaljeret -beskrivelse UC 2.06 UC 2.07 UC 5.03 UC 5.07 UC 5.08 UC 5.15 kunde UC 9.80 Opret autorisation Anmod om autorisation Identificer kunde Opret CVR- kunde Opret CPR- kunde Behandl anmodning om oprettelse som Manuel godkendelse af ansøgning B3. Forrretningsservices Sagsbehandlingssystem Kontrol Økonomisystem Vis sagsforløb Teknisk service Beskrivelse B5. UseCases Input Output Fejl Teknisk SLA Noter UseCase reference B1. Forretningsobjekter Service reference Hent_Borgerstamdata Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. KundeNøgle Dato (Date) KundeStamdata UkendtKunde UgyldigDato Svartid på maksimum 2 sekunder. Systemoppetid 99% i intervallet 6:00-22:00. Systemlukning for vedligeholdelse kan ske i intervallet 22:00-6:00, men højest 10 timer om måneden. Noter UC 2.06 Opret autorisation UC 2.07 Anmod om autorisation UC 5.03 Identificer kunde UC 5.07 Opret CVR- kunde UC 5.08 Opret CPR- kunde UC 5.15 Behandl anmodning om oprettelse som kunde UC 9.80 Manuel godkendelse af ansøgning Borger-stamdata C3. Servicearkitektur

102 B6. Workflow Detaljering af processer og Use cases hvor det er nødvendigt Visning af hvordan de enkelte aktører i samarbejde løser en række opgaver i trin. Dette sikrer at arbejdsdelingen mellem forskellige aktører (organisatoriske enheder) afdækkes og forankres. Brug for eksempel UML activity diagram

103 B6. Workflow Gode råd Det er essentielt, at de arkitekter der faciliterer opgaven, er i stand til at lytte til brugernes behov og ønsker, og tænke i behov frem for teknologi. Workflows er både anvendelige internt, og som materiale i en kravspecifikation.

104 B6. Workflow Metode Workflows detaljerer Use cases, viser hvordan opgaverne løses, og af hvem. Workflows skal primært være de fremtidige hvordan brugerne forestiller sig at arbejde med nye systemer. Der kan være faser af workflows, svarende til faser i implementeringen af den fremtidige arkitektur. Man kan godt tegne de nuværende workflows op først, som en hjælp til at designe de fremtidige. Ikke en en-til-en sammenhæng mellem et workflow og en Use case. Workflows og forretningsregler udarbejdes gerne i sammenhæng.

105 Agenda

106 Agenda

107 Agenda

108 Forretningsobjekter fra i B1 videreudvikles til en egentlig informationsmodel. Der beskrives også database-strukturer og dataflows, på et logisk niveau. Forretningens services (B3) videreudvikles til nogle tekniske services og operationer, ofte med SLAer. Services relateres ofte til de informationsobjekter og applikationer der indgår i at realisere dem. OIO EA metode Teknik Teknik C1. Informationsarkitektur C3. Servicearkitektur C2. Applikationsarkitektur C4. Teknologiarkitektur Her defineres applikationsstruktur hvilke applikationer findes/skal findes, og hvordan de er/fremover skal integreres. Der defineres både generelle valg ( mønstre ) og konkrete applikationer og integrationer. Applikationer/integrationer relateres ofte til dataflows. Generelt: Både AS-IS og TO-BE situation beskrives. Her defineres den underliggende infrastruktur der kan understøtte C1-C3. Dette omfatter: -Teknologi referencemodel -Konkrete teknologistrukturer, med byggeblokke og strukturer

109 C1. Informationsarkitektur Oversigt Formål: At definere den nuværende (AS-IS) og fremtidige (TO-BE) informationsarkitektur Elementer: At etablere en logisk datamodel At definere database strukturer At definere/etablere konkrete datastandarder Primære aktører: Informationsarkitekt Enterprise arkitekt Organisationens informationsmodellører Organisationens databaseadministratorer

110 C1. Informationsarkitektur Leverancetyper OIO EA C1.1 C1.2 C1.3 C1.4 foreslår fire typer leverancer: Informationsmodeller i Logisk Data Model Data distribution Database-oversigt Fysisk datamodel, inkl. OIOXML

111 C1. Informationsarkitektur C1.1 Informationsobjekter i LDM Forretningsobjektmodellen (begrebsmodellen), B1, beskriver begreberne som forretningen ser dem Væsentligste objekter Beskrivelse af disse Væsentligste relationer Måske visse kardinaliteter Måske væsentligste attributter

112 C1. Informationsarkitektur C1.1 Informationsobjekter i LDM C1.1 videreudvikler forretningsobjektmodellen til en mere implementeringsnær informationsmodel Flere objekter af mere teknisk art, der ikke er så vigtige for forretningen Komplet specifikation af relationer og kardinaliteter Temmelig komplet specifikation af attributter

113 C1. Informationsarkitektur C1.4 Fysisk datamodel, inkl. OIOXML Links fra informations-model til OIO-datastandard = Semantik + Syntaks

114 C1. Informationsarkitektur C1.2 Data distribution Data objekter spredt ud på lokationer/organisatoriske enheder CRUD på lokationsniveau Data fragmentering (horisontal/vertikal) Data flows og integrationskarakteristika (se også C2-leverancer) Kan dokumenteres i matrixform eller som diagram (views)

115 C1. Informationsarkitektur C1.2 Data distribution Horisontal data fragmentering - al information, men kun om udvalgte rækker

116 C1. Informationsarkitektur C1.2 Data distribution Vertikal data fragmentering noget information, om alle rækker

117 C1. Informationsarkitektur C1.2 Data distribution Borger Virksomhed CR CR Rådhus Borgmesterkontor Indkøb RU Sagsbehandling Bogholderi CRUD RU Jobcenter Jobcenter Jobcenter CPR-register

118 C1. Informationsarkitektur C1.3 Database-oversigt For hver database Navn Lokationer Logiske database objekter (begreber) indeholdt Applikationer der bruger den # records, samlet volume Data kvalitet Volatilitet Database teknologi Platform teknologi Ejer

119 C2. Applikationsarkitektur Oversigt Formål: At definere den nuværende (AS-IS) og fremtidige (TO-BE) applikationsarkitektur Elementer: At etablere strategiske valg af applikations- og integrationsmønstre At definere applikationers support for processer Ar definere applikations- og integrationslandskab Primære aktører: Applikationsarkitekt Enterprise arkitekt Organisationens applikationsudviklere

120 C2. Applikationsarkitektur Leverancetyper OIO EA foreslår syv typer leverancer: C2.1 Applikationskatalog C2.2 Applikation-information map (C1.1-C2.1) C2.3 Applikation infrastruktur mønstre C2.4 Applikation-proces map (B4.1-C2.1) C2.5 Integrationskatalog C2.6 Integrationsstrategi og integrationsmønstre C2.7 Applikation-integration views (C2.1-C2.5-C1.1 kombineret)

121 C2. Applikationsarkitektur C2.7 Applikation-integration views (AS-IS) Borger Henvendelse Henvendelse Sagsbehandling A Sagsbehandler Borger Sagsbehandling B Arbedsstation Arbedsstation filoverførsel Økonomi A Opslag v. DB query filoverførsel filoverførsel filoverførsel Økonomi B Arbedsstation filoverførsel CPR filoverførsel filoverførsel Sagsbehandler filoverførsel filoverførsel Manuelt opslag Manuelt opslag Ny applikation Eksisterende applikation, fortsætter uændret BBR SKAT Eksisterende applikation, modificeres Eksisterende applikation, udgår

122 C2. Applikationsarkitektur C2.7 Applikation-integration views (TO-BE) Henvendelse Borger Borgerportal Henvendelse Opsamling Opsamling Ledelses information Sagsbehandling Sagsbehandler Arbedsstation Opsamling Beslutningstager filoverførsel begivenhed Økonomi begivenhed Ny applikation Integrationsbus begivenhed CPR begivenhed begivenhed BBR Eksisterende applikation, fortsætter uændret SKAT Eksisterende applikation, modificeres Eksisterende applikation, udgår

123 Den røde tråd i OIO EA - baseret på processer Vis ion Må l Str ate gie r Borger Indgiv ansøgning Kri tisk e suc (KS cesfa Fer k to ) r Modtag udbetaling Af slag Start Ansøgning Af slag Udbetaling Sagsbehandler Kontroller ansøgning f or f ormalia er Begrund og send afslag Gentoptag sagsbehandling Nej Nej Sagsbehandling Formalia overholdt? ja A nsøgning imødekommet? Henvendelse Ja Borger Økonomi Start udbetaling A5. Vision, mål og strategier Borgerportal Nej Kontrol Kontrol Er udbetaling i Ja orden? Henvendelse Opsamling Stop Opsamling B4. Forretningsprocesser Ledelses information Sagsbehandling Sagsbehandler Arbedsstation Opsamling Beslutningstager filoverførsel begivenhed Økonomi begivenhed Integrationsbus begivenhed CPR begivenhed begivenhed BBR SKAT C2.7 Applikation-integration views B1. Forretningsobjekter C4. Teknologiarkitektur

124 C3. Servicearkitektur Oversigt Formål: At udvikle Forretningsservice-modellen fra B3. til en teknisk servicearkitektur Elementer: At definere teknologi-services, og at koble disse til de elementer i forretningen de understøtter (forretningsmæssige services, UseCases, processer, begrebsmodel) At definere en komponent-opdelt applikationsarkitektur Primære aktører: Applikationsarkitekt, informationsarkitekt Enterprise arkitekt Organisationens applikationsudviklere

125 C3. Den enkelte service: en kontrakt mellem servicemodtager og serviceudbyder Forretningsmæssigt niveau: mellem Kunde slutbruger og forretningsserviceleverandør: Service Forretningsservices Tekniske niveau: mellem forretningsserviceleverandør og teknisk leverandør SLA for Forretnings services Service Forretningsservices Teknisk Servicearkitektur SLA for Tekniske services

126 B3. Hvad er SOA? Forretningsmæssig synsvinkel Forretningsrelaterede services ikke teknologi! Services er kontraktbaserede Fokus på gevinst: Agilitet : hurtig reaktion på en ny situation ændrede lovkrav, ny markedssituation, nye produkter, Genbrugelighed den samme service skal kunne bruges i flere løsninger Leverandøruafhængighed man kan vælge den bedste leverandør af en given service (BBR, kreditrating, valutakurs, )

127 C3. Hvad er SOA? Teknisk synsvinkel SOA er et arkitekturprincip (et mønster) Services er genbrugelige, kan sammensættes Services er løst koblede Services er lokations-uafhængige Services er platformsuafhængige Fokus på interoperabilitet (nem integration integrationsbus) Brug af åbne standarder for data og teknologi Specifikation og implementering af en service er adskilte Services er kontraktbaserede Service-view på hvad it skal levere til forretningen Services kan leveres fra mange leverandører Services kan styres Tættere koblet til drift til forskel fra en monolitisk applikation kan det nemmere (via SLAs) identificeres hvilken service der fejler Vision: services registreres og kan opdages og bruges Vision: selv-helende services er den ikke tilgængelig fra en udbyder, er der andre

128 C3. SOA vision bruger bruger bruger bruger bruger bruger bruger bruger bruger Fælles portal Integrationsbus Applikation Applikation Ekstern applikation

129 B3. Eksempel: Kunde Kunde

130 B3/C3. Kunde -servicen som eksempel UseCases UC 5.47 Generer udtræk af kundedatabase til ESDH ESDH UC 5.43 Automatisk opdatering af kunde Timer GLR UC 5.15 Behandl anmodning om oprettelse som kunde UC 5.08 Opret CPR- kunde «include» «include» UC 5.42 Opret kunde «include» «include» Sagsbehandler «include» CPR UC 5.07 Opret CVR- kunde «include» «include» CVR Kunde «Kundeservice» Autorisationselement Refererer til 0..* «Sag service» +modtagerstatus +udstederstatus +startdato +slutdato +autorisationniveau [0..1 no] +fuldautorisationtype [0..1 no] «Skemaservice» «metaclass row» indgår i 0..1 Ansøgning Sag +AnsøgningsID Forretningsservice +Sagsnummer 0..* Indsender 0..* 0..* Opret Kunde Opdater kunde automatisk Opdater kunde manuelt Beskriver 1 «Kundeservice» Kunde 1 +KundeID 0..* Ejer «Kundeservice» Areal Har 0..* «Kundeservice» Besætning «Kundeservice» Produktionsapparat 0..* 1 «Kundeservice» 1 1 «Kundeservice» Kommer fra Fartøj Produktion 0..* * Foretages i ft Teknologiservice Har udstedt 0..* relaterer til * Har modtaget Har 0..* «Kundeservice» 1 Kundeskifte Base Kunde.Opret Kunde.Stamdata_Hent Kunde.Stamdata_Ret Kunde Produktionsapparat Autorisationer og f uldmagter ServiceA gent Kundeskif te Metadata

131 C3. SOA kan gennem SLAs give leverandøruafhængighed bruger Kunde «Kundeservice» Autorisationselement Refererer til 0..* «Sag service» +modtagerstatus +udstederstatus +startdato +slutdato +autorisationniveau [0..1 no] +fuldautorisationtype [0..1 no] «Skemaservice» «metaclass row» indgår i 0..1 Ansøgning Sag SLA for Forretnings services +AnsøgningsID +Sagsnummer 0..* 0..* 0..* Indsender Opret Kunde Opdater kunde automatisk Opdater kunde manuelt * Beskriver 0..* Har udstedt Har modtaget Har relaterer til 1 «Kundeservice» Kunde 1 +KundeID 0..* Ejer «Kundeservice» Areal Har 0..* «Kundeservice» Besætning «Kundeservice» Produktionsapparat 0..* 1 «Kundeservice» 1 1 «Kundeservice» Kommer fra Fartøj Produktion 0..* * Foretages i ft 0..* «Kundeservice» 1 Kundeskifte Ny SLA for Tekniske services Base Kunde.Opret Kunde.Stamdata_Hent Kunde.Stamdata_Ret Kunde Produktionsapparat Autorisationer og f uldmagter ServiceAgent Kundeskif te Metadata Create_user Get_user Modify_user Autorisationskomponenten Hjælperegisterkomponente Ordningskomponente Parameterkomponente

132 C3. Servicearkitektur Leverancetyper OIO EA foreslår tre typer leverancer: C3.1 Serviceoversigt (top-down) C3.2 Komponentopdelt applikationslandskab (bottom-up) C3.3 (Web)service-forretningsservice map (B3.1-C3.1) (videre vej mod implementering)

133 Den røde tråd i OIO EA - baseret på services og Use cases En SOA fra bunden, revolution tilgang Borger Indgiv ansøgning Modtag udbetaling Trin Beskrivelse Aktører Services Objekter 1. Borger klikker på sagsoversigt i Borgerportalmenu. Borger Kunde.HentKundeSt amdata( Kunde_ID) Borger Borger tilgår detaljerede oplysninger om de enkelte sager Borger Sag.Hent [Journalnummer] (Henter oplysninger om sagen) Borger Af slag Start 2. Borgerportal Ansøgning Af slag Sagsbehandlingssystem Udbetaling Sagsbehandler Kontroller ansøgning f or f ormalia Borgerportal Begrund og send afslag Gentoptag sagsbehandling Nej Nej Sagsbehandling Formalia overholdt? ja A nsøgning imødekommet? Økonomi Start udbetaling Nej Kontrol Kontrol Er udbetaling i Ja orden? Opret borgerkonto Systemadministrator Stop Henvendelse B4. Forretningsprocesser Borger-stamdata Be skrivelse Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. Borgerens identifikation Dato Borgerens stamdata Sag Hændelse Sag.Akt_List [Journalnummer] (Viser alle hændelser på sagen, som aktøren har adgang til at se) Input Output Sag.Akt_Hent [Journalnummer, Aktnummer] (Henter netop én hændelse og de oplysninger, der er knyttet til hændelsen) Ja Forretningsmæssig se rvice Sag.Doku ment_list [Aktnummer] (Viser evt. dokumenter journaliseret på hændelsen) Fe jl Borgeren har ikke identificeret sig genkendeligt Dato er uden for intervallet Forretningsmæssig SLA Brugeren (borgeren/sagsbehandleren ) skal have adgang til de registrede informationer 24 timer i døgnet, bortset fra eventuelle system-nedetider, der maksimalt andrager 2 timer i intervallet per døgn. Borgeren have nem adgang til at indsende opdateringer til oplysningerne. Borgeren skal kunne se sine informationer via en sikker, krypteret forbindelse. Note r UseCase re fe rence Borgerportal Opret sag Inf ormer om at sag er oprettet CPR/CVR/BBR Borger Sagsbehandling Sagsbehandler Udbetaling Sagsbehandlingssystem Kontrol B5. Use cases -detaljeret -beskrivelse UC 2.06 UC 2.07 UC 5.03 UC 5.07 UC 5.08 UC 5.15 kunde UC 9.80 Opret autorisation Anmod om autorisation Identificer kunde Opret CVR- kunde Opret CPR- kunde Behandl anmodning om oprettelse som Manuel godkendelse af ansøgning B3. Forrretningsservices Økonomisystem Vis sagsf orløb Teknisk service Beskrivelse B5. Use cases Input Output Fejl Teknisk SLA Noter UseCase reference B1. Forretningsobjekter Service reference Hent_Borgerstamdata Henter borgerens stamdata i kunderegisteret. I samme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specificeres, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. KundeNøgle Dato (Date) KundeStamdata UkendtKunde UgyldigDato Svartid på maksimum 2 sekunder. Systemoppetid 99% i intervallet 6:00-22:00. Systemlukning for vedligeholdelse kan ske i intervallet 22:00-6:00, men højest 10 timer om måneden. Noter UC 2.06 Opret autorisation UC 2.07 Anmod om autorisation UC 5.03 Identificer kunde UC 5.07 Opret CVR- kunde UC 5.08 Opret CPR- kunde UC 5.15 Behandl anmodning om oprettelse som kunde UC 9.80 Manuel godkendelse af ansøgning Borger-stamdata C3. Servicearkitektur

134 C3. Servicearkitektur C3.1 Serviceoversigt (serviceoperation) Teknisk service Beskrivelse <Service-navn> Hvad leverer servicen? Input Hvad kræver servicen af input? Output Hvad leverer servicen? Fejl Hvilke fejlmuligheder kan der være? Teknisk SLA Hvilke tekniske service level agreements skal der udstilles til brugerne af servicen? Noter Noter UseCase reference Reference til de UseCases der vil bruge de tekniske services Service reference Reference til de forretningsmæssige services hvor man vil benytte denne tekniske service

135 C3.1 Serviceoversigt Teknisk service Beskrivelse Input Output Fejl Teknisk SLA Noter UseCase reference Service reference Hent_Borgerstamdata Henter borgerens stamdata i kunderegisteret. I sa mme søgning afgøres det, om kunden forefindes i GLR. Hvis CVR-nr. ikke findes, returneres en tom værdi. Hvis en dato specifice res, hentes de stamdata der var gyldige på datoen. Hvis ingen dato specificeres, hentes aktuelle stamdata. KundeNøgle Dato (Date) KundeStamdata UkendtKunde UgyldigDato Svartid på ma ksimu m 2 sekunder. Systemoppetid 99% i intervallet 6:00-22:00. Systemlukn ing for vedligeholdelse kan ske i intervallet 22:00-6:00, men højest 10 timer o m måneden. Noter UC 2.06 Opret autorisation UC 2.07 Anmod o m autorisation UC 5.03 Identificer kunde UC 5.07 Opret CVR- kunde UC 5.08 Opret CPR- kunde UC 5.15 Behandl an modning o m oprettelse som kunde UC 9.80 Manuel godkendelse af ansøgning Borger-stamdata Reference til B1. Forretningsobjekter Reference til B5. UseCases Reference til B3. Forretningsservices

136 C3. Servicearkitektur C3.3 (Web)serviceforretningsservice map Forretnings-servicebeskrivelse

137 C3. Servicearkitektur C3.3 (Web)serviceforretningsservice map Mapning af serviceoperationer til Forretnings-servicebeskrivelsen

138 C4. Teknologiarkitektur Oversigt Formål: At definere den nuværende (AS-IS) og fremtidige (TO-BE) teknologiarkitektur Elementer: At etablere strategiske teknologivalg At definere teknologi- byggeklodser At definere system topologier Primære aktører: Teknologi arkitekt Enterprise arkitekt

139 C4. Teknologiarkitektur Leverancetyper OIO EA C4.1 C4.2 C4.3 C4.4 C4.5 foreslår fem typer leverancer: Teknologi referencemodel Arkitektur byggeblokke (ABB) Systemtopologier Udvidede systemtopologier Teknologi inventory

140 C4. Teknologiarkitektur Tilgang (TOGAF-inspireret) Fra generelle teknologivalg til organisations EA C4.1 Teknologi referencemodel C4.2 ABB (Arkitektur ByggeBlokke) C4.3 System topologier C4.4 Udvidede system topologier

141 C4. Teknologiarkitektur C4.1 Teknologi referencemodel (eksempel)

142 C4. Teknologiarkitektur C4.2 Arkitektur byggeblokke Sammenstykninger af hardware og software komponenter der udgør en standard logisk enhed Afdelingsserver F FT TP P FTP F ile a n d P r in t S e r v ic e s W e b S e rv e r Tow er box Basis hardware - software

143 Agenda

144 Agenda

145 Agenda

146 Der identificeres restriktioner af teknisk og forretningsmæssig art. Der kan laves en risikoanalyse hvor alvorligt er risici, og hvad kan der gøres for at minimere indflydelsen? OIO EA metode Gap analyse Gap analyse D1. Restriktioner D3. Gap analyse D2. Muligheder Der identificeres muligheder muligvis af mere taktisk end strategisk natur der kan give organisationen hurtige gevinster. Gap analysen analyserer forskellene mellem den nuværende (AS-IS) arkitektur og den ønskede fremtidige (TO-BE). Sammen med trin D1 og D2 skabes dermed et fundament for migreringsplanen.

147 Gap analyse D1. Restriktioner D1.1 Restriktioner, konsekvenser og alternativer Restriktioner beskrives Forretningsmæssige Vi kan ikke få råd til X før 2009 Politiske Område X kræver a fortsætte med applikation Y af hensyn til lovgivning Økonomiske Afd. Z vil ikke acceptere teknologi W Konsekvenser beskrives for hver restriktion Alternativer beskrives Er der workarounds der kan afhjælpe restriktionen? Tekniske Teknologi X understøtter ikke Y Vi har ikke kompetence indenfor W Skal vi både have gammel applikation Y og ny Z, kræver det dobbeltindtastning En integration af Y og Z vil kunne foretages for XX.XXX kroner Vi hyrer expertise indenfor W

148 Gap analyse D1. Restriktioner D1.2 Risikoanalyse Risici er mulige restriktioner de kan indtræffe eller ej For hver risiko: Beskrivelse Vigtighed hvor alvorlig er risikoen? Sandsynlighed for at risikoen indtræffer Indflydelse på planlægning: vigtighed sandsynlighed Contingency hvad kan gøres hvis risikoen realiserer sig Der vil være restriktioner/risici Husk løbende at opdatere restriktioner og risici, efterhånden som de opdages/ændres EA governance! Husk at opdateringer kan føre til ændringer i gap analysen og migreringsplanen!

149 Gap analyse D2. Muligheder D2.1 Muligheder, vigtighed og indsats En mulighed er måske ikke strategisk (del af EA), men et taktisk tiltag der kan give besparelser, bedre effektivitet, og bedre kvalitet Beskriv Projektets indhold Vigtighed, gevinst Indsats påkrævet Samlet nytte = vigtighed/indsats (lavthængende frugter) Ejer af mulighed Indstilling hvad gøres Metode: Under udvikling af EA, så spørg ind til muligheder der er typisk en masse gode ideer der bare aldrig er kommet frem Saml og prioritér mulighederne (workshop) God ide at bringe muligheder under EA governance

150 Gap analyse D3. Gap analyse Identificer og beskriv de skridt der logisk skal til for at etablere TO-BE arkitekturen IKKE en projektplanlægning af trinene ingen tid/penge/aktivitetsanalyse AS-IS TO-BE

151 Gap analyse D3. Gap analyse Gruppér trinene i beslægtede indsatsområder (Se trin næste side) Infrastruktur AS-IS TO-BE Integrationsplatform Borgerportal Ledelsesinformation

152 Gap analyse D3. Gap analyse Infrastruktur Sikr at infrastrukturen kan håndtere TO-BE Integrér applikationer til integrationsplatform Integrér integrationsplatform til borgerportal Integrér integrationsplatform til ledelsesinformationssystem Integrationsplatform Udvælg teknologi (produkt) Udvælg leverandør Implementer integrationsplatform Borgerportal Udvælg teknologi Udvælg leverandør Implementér borgerportal Markedsfør borgerportal Ledelsesinformation Specificer forretningsspørgsmål for ledelsesinformation (B1.3) Specificer standarder for forretningsobjekter der indgår i forretningsspørgsmål (C1.4) Udvælg teknologi Udvælg leverandør Implementer ledelsesinformationssystem Uddan i ledelsesinformationssystem

153 Der udarbejdes en overordnet tilgang til migreringen. Forretningen, systemejere og driftsansvarlige inddrages. Temaer: big-bang versus gradvise ændringer, hvordan besluttes migreringsprojekter?, osv. OIO EA metode Forandring Forandring E1. Migreringsstrategi E2. Migreringsplan E3. Konsekvens analyse Der udarbejdes en højniveau-projektplan for de kommende migreringsprojekter. De enkelte specificeres i nogen detalje, med estimater på tidsplan, aktiviteter, ressourceforbrug, osv. Konsekvenserne af foreslåede migreringsprojekter analyseres, mht. årsag til konsekvenser, og mht. hvilken indsats der evt. skal gøres.

154 E. Forandring E1.1 Migreringsstrategi Overordnet ramme principper Big bang versus evolution Proaktivitet versus reaktivitet (projekter initieres ud fra migreringsplan, versus projekter opstår fra initiativer udenfor EA governance) Vurderingsskala af migreringsprojekter kort sigt versus lang sigt Tilgang til forandringsledelse Tæt knyttet til EA governance

155 E. Forandring E2. Migreringsplan Gennemgå de indsatsområder og trin der er identificeret i gap analysen. Vurder: Omfang af trinet i mandmåneder Omfanget af trinet i kalendertid (kan flere arbejde på det, og dermed afkorte varigheden?) Værdi af trinet i tid/penge/kvalitet Afhængigheder mellem trin hvilke trin skal være færdige før et givet trin kan udføres? Eksterne afhængigheder må trinet afvente eksterne ting såsom tilgængelighed af ressourcer, tidspunkter, release af software, Gennemgangen kan give anledning til modfikation af trin Organisér trinene i et ganttchart, under hensyn til afhængigheder og at få mest værdi hurtigt

156 E. Forandring E2.1 Migreringsplan 2008 AS-IS TO-BE

157 E. Forandring E3.1 Konsekvensanalyse Beskriv konsekvenser af hver enkelt migreringsprojekt Vi vil i det første år skulle vænne os til de nye systemer en usikkerhed borgeren kan opleve som dårligere service Beskriv indsats for at imødegå konsekvenserne Det skal kommunikeres til borgerne hvilke fordele de nye systemer har for dem på sigt, og at de kun behøver at skifte når de føler sig trygge ved skiftet

158 Agenda

159 OIO EA metode Strategi Strategi A1. EArelaterede udfordringer A3. EA metodegrundlag A5. Vision, mål og strategier A2. EA governance strategi A4. Projekt charter A6. It-principper Det sikres at der foreligger en governance strategi allerede inden projektstart, og at der er topledelsesopbakning til at sikre implementering af EA-arbejdets anbefalinger (ellers bliver det næppe en succes).

160 A2. EA governance strategi the basics EA governance er essentielt!!! En arkitektur der ikke bliver brugt har ingen værdi Fordele som SOA kommer kun ved styring på tværs af projekter EA governance IT governance EA governance er forskellig fra organisation til organisation Afklar i A2.: EA governance vision ( Budget ) EA governance mål EA governance strategi Pisk eller gulerød? EA governace KSFer Identificer EA governance organisationselementer Identificer processer Udvikling/vedligehold af EA Kommunikation af EA EA projekt review EA kompetencesikring EA leverance-kvalitetskontrol EA modenhed/fremdrift EA metodetillempning

161 A2. EA governance strategi Arbejdsmodel elementer i organisation Styregruppe Arkitektur board Enterprise arkitekt Dokumentationssteward Ar b r ej d p pe u sgr r g up p j ds e er b Ar Projekter

162 A2. EA governance strategi Enterprise arkitekt En enterprise arkitekt er metode-fyren Har autoritet og gennemslagskraft i organisationen Er bred (ikke dyb) Teknisk Forretningsmæssigt Organisatorisk Styregruppe Arkitektur board Enterprise arkitekt Dokumentationssteward Arb er ej d up p sgr r g s up p ej d er A rb Kan ikke alt men kan se når nye initiativer kræves, og kan definere disse Er proaktiv i at initiere nye aktiviteter Er vejleder og daglig kontakt til arbejdsgrupper og dokumentationsstewarden Forbereder informationer og anbefalinger til AB, og leder typisk AB møder

163 A2. EA governance strategi Enterprise arkitekt fortsat En enterprise arkitekt kan være én person eller en gruppe Nok mest effektivt med én person, der dækker evt. manglende kompetencer ind via hjælp fra andre OIO EA rummer forslag til kompetencer for en enterprise arkitekt

164 A2. EA governance strategi Dokumentationssteward Styregruppe En dokumentationssteward er ansvarlig for at sikre at der udvikles og vedligeholdes en EA-dokumenEnterprise arkitekt tationsramme Arkitektur board Valg af modeller (UML, BPMN, ) Valg af rapportformer Valg af værktøjer A rb ej d sgr up per Dokumentationssteward r p pe u r sg ej d b r A er ansvarlig for at at konkrete projekter og initiativer forstår og bruger dokumentationsrammen er ansvarlig for at ændringer/ændringsønsker kommunikeres til interessenter (både interne og eksterne leverandører der skal følge dem)

165 EA governance Barrierer Kompetencemæssige Organisatoriske Finansielle / ressourcer Personer Vær ærlig omkring barrierer søg måder at omgå dem Kulturelle Teknologiske

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7 OIO Serviceprincipper Version: 1.1 Status: i høring i PF for GD1 og GD2 Oprettet: 4. juni 2014 Dato: 4. juni 2014 Dokument historie Version Dato Beskrivelse

Læs mere

Fælles overblik over it-arkitekturen (UDKAST)

Fælles overblik over it-arkitekturen (UDKAST) Fælles overblik over it-arkitekturen (UDKAST) Digitaliseringsstrategiens initiativ 9.4 - Fælles overblik over it-arkitekturen Formål: At levere rammen og grundlaget for et fælles overblik over it-arkitekturen

Læs mere

Oplæg ved AEA - EA netværk EA i Gentofte Kommune. På ITU den 6 marts 2013

Oplæg ved AEA - EA netværk EA i Gentofte Kommune. På ITU den 6 marts 2013 Oplæg ved AEA - EA netværk EA i Gentofte Kommune På ITU den 6 marts 2013 CV Sarah Ebler - Enterprise Arkitekt Gentofte Kommune Erhvervserfaring: Enterprise Architect - Gentofte Kommune - 01.10.2011 - nuværende

Læs mere

KORT OM PROJEKTPORTEFØLJESTYRING. Af Jacob Kragh-Hansen, Execution Consulting Group

KORT OM PROJEKTPORTEFØLJESTYRING. Af Jacob Kragh-Hansen, Execution Consulting Group KORT OM PROJEKTPORTEFØLJESTYRING Af Jacob Kragh-Hansen, Execution Consulting Group KORT OM PROJEKTPORTEFØLJESTYRING INDHOLD 1 PROJEKTPORTEFØLJESTYRING 2 TYPISKE UDFORDRINGER 3 RATIONALE & GEVINSTER 4 ANBEFALET

Læs mere

ZEBRANET. Serviceorienteret Arkitektur. Enterprise Architecture Trends og Perspektiver. Allan Bo Rasmussen Zebranet ApS abr@zebranet.

ZEBRANET. Serviceorienteret Arkitektur. Enterprise Architecture Trends og Perspektiver. Allan Bo Rasmussen Zebranet ApS abr@zebranet. Enterprise Architecture Trends og Perspektiver E-BUSS konference 14. september 2007 Allan Bo Rasmussen Zebranet ApS abr@zebranet.dk ZEBRANET Serviceorienteret SOA og Enterprise Architechture Definitioner

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Strategi 2013-2017 Danmarks Miljøportal

Strategi 2013-2017 Danmarks Miljøportal Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

Læs mere

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering OI OXML som obligatorisk, åben standard - uddybende vejledning 1 Om dette dokument Dette dokument beskriver anbefalet praksis for at anvende OIOXML som åben, obligatorisk standard. IT- og Telestyrelsen

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

leverer forventet udbytte Kun 10% af strategiske projekter

leverer forventet udbytte Kun 10% af strategiske projekter leverer forventet udbytte Kun 10% af strategiske projekter Hvem er Crevato Crevato er et professionelt konsulenthus der bistår danske og internationale virksomheder i forbindelse med: Strategi Portefølje

Læs mere

Den nye fælles offentlige kravspecifikation. v/ projektleder Anna Schou Johansen

Den nye fælles offentlige kravspecifikation. v/ projektleder Anna Schou Johansen Den nye fælles offentlige kravspecifikation v/ projektleder Anna Schou Johansen Mål og visioner for kravspecifikationen Øget intern og ekstern sammenhæng Effektivisere indkøb og systemopbygning Optimering/effektivisering

Læs mere

Aktstykke nr. 28 Folketinget 2009-10. Afgjort den 19. november 2009. Økonomi- og Erhvervsministeriet. København, den 9. november 2009.

Aktstykke nr. 28 Folketinget 2009-10. Afgjort den 19. november 2009. Økonomi- og Erhvervsministeriet. København, den 9. november 2009. Aktstykke nr. 28 Folketinget 2009-10 Afgjort den 19. november 2009 28 Økonomi- og Erhvervsministeriet. København, den 9. november 2009. a. Økonomi- og Erhvervsministeriet anmoder om Finansudvalgets tilslutning

Læs mere

Fra idé til drift i praksis!

Fra idé til drift i praksis! Fra idé til drift i praksis! Design Coordination @ITIL Dagen 2014, 3/12-2014 JonasEllegaard ServiceManagement Om mig } Ansvarlig for Leverandørstyring } Skabe værdi } Systemetableringsprocessen } ITIL

Læs mere

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense CPR Broker version 2.0 Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense Steen Deth, Chefarkitekt sde@gentofte.dk CPR data hvor svært (og interessant) kan det være? Kommune Borgerservice

Læs mere

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt

Scope Management ITU 11-09-2013 @janhmadsen #ituscpmgt Scope Management ITU 11-09-2013 @janhmadsen Dagsorden Oplægsholder Projektstyring Scope Management i en fælles kontekst Definitioner Scope Management - styring af omfang ved projektets start under projektets

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem

Arkitekturrapport: Kommunernes Ydelsessystem (KY) Arkitekturrapport: Kommunernes Ydelsessystem Arkitekturrapport: Kommunernes Ydelsessystem 1 Indholdsfortegnelse Baggrund for projekt... 3 Resultat af gennemført arkitekturanalyse... 5 Anvendelse af forretningsservices... 9 Baggrund for projekt Baggrund

Læs mere

I 2011 blev OIO EA, FORM og STORM samlet i Digitaliseringsstyrelsen, og der har siden pågået et arbejde med at sikre sammenhængen i disse værktøjer.

I 2011 blev OIO EA, FORM og STORM samlet i Digitaliseringsstyrelsen, og der har siden pågået et arbejde med at sikre sammenhængen i disse værktøjer. Et fælles overblik over it-arkitekturen UDKAST Baggrund I 2011 blev OIO EA, FORM og STORM samlet i Digitaliseringsstyrelsen, og der har siden pågået et arbejde med at sikre sammenhængen i disse værktøjer.

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Januar 2014 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Indhold. Principstyret EA i relation til OIO EA rammeværket.

Indhold. Principstyret EA i relation til OIO EA rammeværket. Indhold Principstyret EA i relation til OIO EA rammeværket. v/per Madsen, CTO Sirius IT. Sådan koblede E&S principperne til forretnings- og it-strategi. v/niels-peter Rønmos, Chefkonsulent Erhvervs- og

Læs mere

Serviceorienteret arkitektur - Hvad og hvorfor

Serviceorienteret arkitektur - Hvad og hvorfor > Serviceorienteret arkitektur - Hvad og hvorfor IT- & Telestyrelsen November 2006 Indhold > Forord 6 1. Indledning 7 1.1 Formål og baggrund 7 1.2 Målgruppe 8 1.3 Pjecens struktur 8 Del 1 - SOA i den offentlige

Læs mere

Scope dokument for Advisservice

Scope dokument for Advisservice 18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning

Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning Kommissorium for Domænebestyrelsen for Bygninger, Boliger og Forsyning Introduktion Besluttet af Styregruppen for Tværoffentligt Samarbejde, marts 2008 I forlængelse af den fællesoffentlige strategi for

Læs mere

IT og økonomi. Organisering af IT. Strategi og planlægning. Systemudvikling 3 Systemudvikling og systemanskaffelse. Hovedopgaver

IT og økonomi. Organisering af IT. Strategi og planlægning. Systemudvikling 3 Systemudvikling og systemanskaffelse. Hovedopgaver IT og økonomi Systemudvikling 3 Systemudvikling og systemanskaffelse Organisering af IT Hovedopgaver Strategi og planlægning Udvikling og anskaffelse Drift Brugersupport Strategi og planlægning Topledelsen

Læs mere

Business case. for. implementering af InCare på plejecenter med 40 beboere

Business case. for. implementering af InCare på plejecenter med 40 beboere Dato: 2012 J.nr.: xx Business case for implementering af InCare på plejecenter med 40 beboere Version: 3.2 2/11 Indholdsfortegnelse 1. Ledelsesresume... 3 2. Løsningsbeskrivelse... 4 Projektets navn eller

Læs mere

360 Digital Styringsreol

360 Digital Styringsreol 360 Digital Styringsreol OPNÅ BEDRE STYRING, OPFØLGNING, OVERBLIK SAMT DOKUMENTATION AF ORGANISATIONENS PROCESSER Mange organisationer oplever et voksende pres for på samme tid at skulle levere højere

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014 UC Effektiviseringsprogrammet Projektgrundlag Fælles UC Videoplatform 08-05-2014 Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen Produkt: Projektgrundlag, ver. 27/8-2013 1 Stamdata Stamdata

Læs mere

SharePoint 2007 Fælles platform for kommunikation, videndeling og samarbejde. Uffe Meiner Markedschef, Creuna Danmark A/S (uffe.meiner@creuna.

SharePoint 2007 Fælles platform for kommunikation, videndeling og samarbejde. Uffe Meiner Markedschef, Creuna Danmark A/S (uffe.meiner@creuna. Inspirationsseminar SharePoint 2007 Fælles platform for kommunikation, videndeling og samarbejde Uffe Meiner Markedschef, Creuna Danmark A/S (uffe.meiner@creuna.dk) Formål Inspiration til udnyttelse af

Læs mere

Risikostyring ifølge ISO27005 v. Klaus Kongsted

Risikostyring ifølge ISO27005 v. Klaus Kongsted Risikostyring ifølge ISO27005 v. Klaus Kongsted Agenda Dubex A/S Formålet med risikovurderinger Komponenterne Risikovurderinger Dubex A/S fakta og værdier Den førende sikkerhedspartner De bedste specialister

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

Bilag: Resultat af spørgeskemaundersøgelse

Bilag: Resultat af spørgeskemaundersøgelse Bilag: Resultat af spørgeskemaundersøgelse Hvad er din titel? Student senior it-konsulent It-udviklings- og digitaliseringskonsulent Projektleder IKT-driftchef Projektleder enterprise architect Systemadministrator

Læs mere

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus 4. oktober 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y DEVOTEAM i Danmark og i Europa 2 Devoteam

Læs mere

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt.

Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. 8. april 2013 19-Partskontakt => Kontaktdata Indledning Dokumentet indeholder et oplæg til fastlæggelse af scope for realisering af forretningsservicen Partskontakt. I de oprindelige oplæg med visionen

Læs mere

Fremtidsmodel (Blueprint) - Vejledning

Fremtidsmodel (Blueprint) - Vejledning Fremtidsmodel (Blueprint) - Vejledning Januar 2014 Indhold 1. FORKLARING PÅ CENTRALE BEGREBER... 3 2. HVAD ER FREMTIDSMODELLEN (BLUEPRINT)... 4 3. FORMÅLET MED FREMTIDSMODELLEN... 4 4. HVEM MODTAGER FREMTIDSMODELLEN...

Læs mere

Kundecase Region Syddanmark. Ivan Bergendorff Søborg, 7. november 2013

Kundecase Region Syddanmark. Ivan Bergendorff Søborg, 7. november 2013 Kundecase Region Syddanmark Ivan Bergendorff Søborg, 7. november 2013 DUBEX SECURITY & RISK MANAGEMENT SUMMIT 2013 Agenda Hvorfor mobility hos Region Syddanmark Behov og forventede gevinster Udvælgelsesprocessen

Læs mere

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013

Opsamling på kommunal høring. Vejle & Roskilde Den 18. Juni 2013 Opsamling på kommunal høring Vejle & Roskilde Den 18. Juni 2013 Dagsorden Velkommen Høringsprocessen frem til udbuddet på KY Resultater fra høringen Udbudsmaterialet kapitel 1 4, 5 og 6 Temaer: EDSH, opgavelisten,

Læs mere

SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne. Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006

SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne. Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006 SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006 19. september 2006 Agenda Udfordringer overvejelser om SOA Visionen driver

Læs mere

Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata

Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata NOTAT MINISTERIET FOR BY, BOLIG OG LANDDISTRIKTER Fordelingen af kommunale gevinster i business casen for initiativet Genbrug af adressedata 18. juli 2012 Sag: /mli-mbbl Baggrund Initiativet Genbrug af

Læs mere

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012 April 2012 Effektiv digitalisering - Digitaliseringsstyrelsens strategi 2012-2015 Baggrund Danmark står med væsentlige økonomiske udfordringer og en demografi, der betyder færre på arbejdsmarkedet til

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

IT-strategi og ROI baseret på IT

IT-strategi og ROI baseret på IT IT-strategi og ROI baseret på IT Indhold Udarbejdelse af en IT-strategi Udarbejdelse af en ROI-case til ledelsen (business case) Praktisk eksempel på Case forløb 10-05-2012 EG Copyright 2 Faser i udarbejdelse

Læs mere

Hvad kommer ITIL V3 og Cobit til at betyde for IT-supporten? Ole Westergaard Westergaard CSM

Hvad kommer ITIL V3 og Cobit til at betyde for IT-supporten? Ole Westergaard Westergaard CSM Hvad kommer ITIL V3 og Cobit til at betyde for IT-supporten? Ole Westergaard Westergaard CSM V3 Westergaard CSM Westergaard CSM 2 Gode konsulenter hænger ikke på træerne! [Indsæt billede af Jakob/Lars/Gitte/Ulla

Læs mere

Tempus Serva. - er NEM IT til alle virksomheder

Tempus Serva. - er NEM IT til alle virksomheder TM - er NEM IT til alle virksomheder Introduktion Virksomheder bør ikke stræbe efter de alt omfattende visioner og tro, at de med analyse og projektmodeller kan udvikle den optimale digitale løsning. I

Læs mere

Fra vision til dagligdag Implementering af EU s reform af landbrugsstøtten. IMPULS, 17. september 2015

Fra vision til dagligdag Implementering af EU s reform af landbrugsstøtten. IMPULS, 17. september 2015 Fra vision til dagligdag Implementering af EU s reform af landbrugsstøtten IMPULS, 17. september 2015 Indhold NaturErhvervstyrelsen Lidt om vores it Implementeringen af landbrugsreformen 14. September

Læs mere

It-delstrategi for administrativ it-anvendelse

It-delstrategi for administrativ it-anvendelse Administrativ DELSTRATEGI 2011-2015 NOTAT It-delstrategi for administrativ it-anvendelse 9. september 2011 Indholdsfortegnelse 1. Formål...2 2. Baggrund...2 3. Vision...3 4. Strategisk retning...3 4.1.

Læs mere

Branchemodeller Detaljerede procesmodeller for

Branchemodeller Detaljerede procesmodeller for Branchemodeller Detaljerede procesmodeller for A-kasser Kommunal forvaltning Entreprenører Produktionsvirksomhed Fagforbund Rådgivning Skadesforsikring Webshop HVAD ER EN PROCESMODEL (DEL 1)? Leverandør

Læs mere

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel

Rollebeskrivelser. Programroller ift. den fællesstatslige programmodel Rollebeskrivelser Programroller ift. den fællesstatslige programmodel Indholdsfortegnelse Rollebeskrivelser... 1 1. Programprofiler... 3 1.1. Formand for programbestyrelse/programejer... 3 1.2. Programleder...

Læs mere

Security & Risk Management Summit

Security & Risk Management Summit Security & Risk Management Summit Hvor og hvornår skaber Managed Security Services værdi? Business Development Manager Martin Jæger Søborg, 6. november 2014 DUBEX SECURITY & RISK MANAGEMENT SUMMIT 2014

Læs mere

Mobility-strategi Hvordan kommer du i gang? Kenneth Rosenkrantz Søborg, 7. november 2013

Mobility-strategi Hvordan kommer du i gang? Kenneth Rosenkrantz Søborg, 7. november 2013 Mobility-strategi Hvordan kommer du i gang? Kenneth Rosenkrantz Søborg, 7. november 2013 DUBEX SECURITY & RISK MANAGEMENT SUMMIT 2013 Agenda Mobility Politik og procedure Virksomhedens modenhed Hvad bør

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning August 2013 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning

Rollebeskrivelser i den fællesstatslige programmodel. - Vejledning Rollebeskrivelser i den fællesstatslige programmodel - Vejledning Januar 2014 Indhold 1. LÆSEVEJLEDNING... 1 2. FORMAND FOR PROGRAMBESTYRELSEN (PROGRAMEJER)... 2 3. PROGRAMLEDER... 3 4. FORANDRINGSEJER...

Læs mere

Sag og Dokument - Høringskonference. Nanna Skovgaard, Kontorchef Center for Offentlig Digitalisering og Indkøb

Sag og Dokument - Høringskonference. Nanna Skovgaard, Kontorchef Center for Offentlig Digitalisering og Indkøb Sag og Dokument - Høringskonference Nanna Skovgaard, Kontorchef Center for Offentlig Digitalisering og Indkøb Jeg vil sige noget om Hvad det er vi gør i Økonomistyrelsen? Erfaringer fra FESD Hvor vi står

Læs mere

Projekter skal ikke styres de skal ledes Microsoft-seminar

Projekter skal ikke styres de skal ledes Microsoft-seminar Projekter skal ikke styres de skal ledes Microsoft-seminar Frank Madsen PA Consulting Group 17. april 2007 Hvor moden er din virksomhed? Taktiske projekt gennemførelser Styret ProjektPortefølje Projektinitiering

Læs mere

God programledelse. Netværk 20.1 2014

God programledelse. Netværk 20.1 2014 God programledelse Netværk 20.1 2014 Grundlæggende definitioner Portefølje Program Projekt 2 Et program dækker ikke kun projekter Tidlige indikatorer Succeskriterier Gevinster/ Effekter Projekter Ad hoc

Læs mere

Arkitekturrapport: KITOS - Kommunens It-Overbliks System

Arkitekturrapport: KITOS - Kommunens It-Overbliks System Arkitekturrapport: KITOS - Kommunens It-Overbliks System Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt.

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Styregruppeformænd i SKAT Kort & godt (plastkort)

Styregruppeformænd i SKAT Kort & godt (plastkort) Håndbogen for Styregruppeformænd i SKAT Kort & godt (plastkort) 80% af alle projekter, hvor der er uigennemskuelighed fejler Lange projekter er mere risikofyldte end korte Transparente projekter har oftere

Læs mere

Ledelse af digitalisering

Ledelse af digitalisering Ledelse af digitalisering SCKK temamøde om digital forvaltning 7. april 2006 Mikael Skov Mikkelsen Finansministeriet msm@fm.dk - www.e.gov.dk Dagsorden Hvorfor og hvordan ledelse af digitalisering? Den

Læs mere

Solutions Day. IT Service Management. Globeteam ITSM

Solutions Day. IT Service Management. Globeteam ITSM Solutions Day IT Service Globeteam ITSM Indhold IT Service Introduktion til ITSM og ITIL Angrebsvinkel til ITIL Case - Kriminalforsorgen ITSM værktøjer Afrunding Hans Christian Holst ITSM konsulent hch@globeteam.com

Læs mere

Overordnede principper og best practice

Overordnede principper og best practice Overordnede principper og best practice Version 1.0, april 2009 Fællesoffentlige it-arkitekturkrav Fællesoffentlige it-arkitekturkrav Overordnede principper og best practice Udgivet af: IT- & Telestyrelsen

Læs mere

CV - Michael Hviid. Januar 2003- august 2008 Rehfeld Partners Projektleder. Juli 1998 - December 2002 Egen konsulentvirksomhed 1998-2002

CV - Michael Hviid. Januar 2003- august 2008 Rehfeld Partners Projektleder. Juli 1998 - December 2002 Egen konsulentvirksomhed 1998-2002 CV - Michael Hviid Kontaktoplysninger Michael Hviid Platanvej 23 4000 Roskilde Mobil 4057 4606 E-mail: mh@zy.dk Profilresume Michael har mere end 20 års erfaring med projekt- og udviklingsarbejde i itbranchen.

Læs mere

Christian Sandbeck, Direktør for KMDs Contract Management

Christian Sandbeck, Direktør for KMDs Contract Management DIAS 1 IMPLEMENTERING AF CONTRACT MANAGEMENT I KMD Christian Sandbeck, Direktør for KMDs Contract Management DAGSORDEN DIAS 2 Hvorfor Contract Management ( CM ) som disciplin i KMD? Introduktion til KMD

Læs mere

Mandag: HVAD ER ET PROJEKT?

Mandag: HVAD ER ET PROJEKT? Mandag: HVAD ER ET PROJEKT? Hvorforhar vi projekter? Resultater! Fokus på en opgave der ikke er mulig i linjeorganisationen Arbejde på tværs af en organisation Afgrænsning af styringsområde Bedre styring

Læs mere

Organisering, opgaver, roller og bemanding (SAPA/Monopolbrud) Thor Herlev Jørgensen Programleder i Lyngby-Taarbæk Kommune for monopolbrudsprojekterne

Organisering, opgaver, roller og bemanding (SAPA/Monopolbrud) Thor Herlev Jørgensen Programleder i Lyngby-Taarbæk Kommune for monopolbrudsprojekterne Organisering, opgaver, roller og bemanding (SAPA/Monopolbrud) Thor Herlev Jørgensen Programleder i Lyngby-Taarbæk Kommune for monopolbrudsprojekterne KolleKolle - 25. November 2013 WS1 sat ind i et lokalt

Læs mere

PMO Forum. Dagens tema: Strategisk beslutningstagning prioritering i en kompleks projektverden

PMO Forum. Dagens tema: Strategisk beslutningstagning prioritering i en kompleks projektverden PMO Forum Dagens tema: Strategisk beslutningstagning prioritering i en kompleks projektverden 1. marts 2012 Agenda 09:00 09:05 Velkomst v. Søren Porskrog 09:05 10:00 Strategisk beslutningstagning i direktionen

Læs mere

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring)

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring) Sektorstandardiseringsudvalget for ehandel Til interessenter i ehandel (udsendes i bred offentlig høring) UDKAST v.2. Høring over vision, pejlemærker og forretningskrav til ehandel mellem den offentlige

Læs mere

Projektkontrakter med fokus på gevinstrealisering. Nicolai Dragsted, Bender von Haller Dragsted. 30. oktober 2012

Projektkontrakter med fokus på gevinstrealisering. Nicolai Dragsted, Bender von Haller Dragsted. 30. oktober 2012 Projektkontrakter med fokus på gevinstrealisering Nicolai Dragsted, Bender von Haller Dragsted 30. oktober 2012 Kontaktoplysninger Advokatvirksomheden BvHD www.bvhd.dk Blog: http://www.version2.dk/blogs/nicolai-dragsted

Læs mere

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU)

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Foranalyse Projekt: PDM-kerne Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Projektdeltagere: 1. Indledning og baggrund Mogens Sandfær (MS), Danmarks Tekniske Universitet (DTU) Jørgen

Læs mere

Den forretningsorienterede mobile IT strategi

Den forretningsorienterede mobile IT strategi Den forretningsorienterede mobile IT strategi v/ Bo Snitkjær Nielsen bsn@globeteam.com 5. Oktober 2011 Globeteam Virumgårdsvej 17A 2830 Virum Indhold Den forretningsorienterede mobile IT strategi Hvorfor

Læs mere

Referencedatamodelprojektet. DDV integrationsmetoden. Version 1.0 23. oktober 2012

Referencedatamodelprojektet. DDV integrationsmetoden. Version 1.0 23. oktober 2012 Referencedatamodelprojektet DDV integrationsmetoden Version 1.0 23. oktober 2012 ISBN: --- Titel: Udgiver: DDV integrationsmetoden DANVA Vandhuset Godthåbsvej 83 8660 Skanderborg Udarbejdet af: Peter Huber,

Læs mere

Effektivisering via krav om elektronisk indberetning af finansielle data Udnytter du mulighederne ved XBRL?

Effektivisering via krav om elektronisk indberetning af finansielle data Udnytter du mulighederne ved XBRL? Effektivisering via krav om elektronisk indberetning af finansielle data Udnytter du mulighederne ved XBRL? Industrigruppe Finans Er du klar til digital indrapportering af finansielle data? Finansielle

Læs mere

DIGITALISERING I DET OFFENTLIGE. Michael Fray, chefkonsulent ITS & ECM

DIGITALISERING I DET OFFENTLIGE. Michael Fray, chefkonsulent ITS & ECM DIGITALISERING I DET OFFENTLIGE Michael Fray, chefkonsulent ITS & ECM AGENDA Hvad er digitalisering Status på papirfri arbejdsgange ECM som næste skridt Konica Minolta og digitalisering 2 DIGITALISERING

Læs mere

www.pwc.dk Sikker implementering af nye fælles it-løsninger

www.pwc.dk Sikker implementering af nye fælles it-løsninger www.pwc.dk Sikker implementering af nye fælles it-løsninger Udfordringer i monopolarbejdet i kommunerne Hvad er koblingen til andre systemer og UDK? Ansvarsfordeling mellem kommune og KOMBIT? Hvad kommer

Læs mere

Agil test tilgang - erfaringer fra projekter

Agil test tilgang - erfaringer fra projekter Agil test tilgang - erfaringer fra projekter af Michael Roar Borlund November 2011 Image Area Agenda Introduktion Agil test Fremtidsvision Agil test tilgang Agil opbygning i QC Resumé og Spørgsmål 2 Introduktion

Læs mere

Sitecore Seminar København onsdag 6. februar 2008 DET DIGITALE DANMARK - BORGERPORTAL 2.0

Sitecore Seminar København onsdag 6. februar 2008 DET DIGITALE DANMARK - BORGERPORTAL 2.0 Sitecore Seminar København onsdag 6. februar 2008 DET DIGITALE DANMARK - BORGERPORTAL 2.0 Om Netmester Netmester A/S 10 års erfaring med web-udvikling Vinder af Bedst til Nettet 2006 og nomineret i 2007

Læs mere

Udvikling og tendenser i projektledelse

Udvikling og tendenser i projektledelse Udvikling og tendenser i projektledelse VIA University College Danmarks største professionshøjskole 2.100 medarbejdere 17.000 studerende VIA Erhverv VIA Pædagogik og Samfund VIA Sundhed VIA Efter- og Videreuddannelse

Læs mere

VELKOMMEN TIL DIALOGMØDE OM MIN DIGITALE BYGGESAG (MDB)

VELKOMMEN TIL DIALOGMØDE OM MIN DIGITALE BYGGESAG (MDB) VELKOMMEN TIL DIALOGMØDE OM MIN DIGITALE BYGGESAG (MDB) Udgangspunkt for Min Digitale Byggesag Pilotprojektet DOB med 6 pilotkommuner, staten og KL Politisk pres i forhold til hurtig, billig og ensartet

Læs mere

Værdibaseret styring og optimering af projektporteføljen

Værdibaseret styring og optimering af projektporteføljen 17. April 2007 Værdibaseret styring og optimering af projektporteføljen Programchef Thomas Steinmetz, G4S Teamleder Charlotte Blou Sand, Creuna Copyright Creuna Danmark A/S Om Creuna Skandinavisk IT-konsulenthus

Læs mere

Fællesskabet der vil noget mere

Fællesskabet der vil noget mere Fællesskabet der vil noget mere Jens Kjellerup Digitaliseringschef Ballerup Kommmune & Bestyrelsen OS 2 - Offentlig Digitaliseringsfællesskab jeh2@balk.dk Tlf. +45 2477 4242 Agenda Digitaliseringslandskabet

Læs mere

Forretningsmæssig prioritering af IT projekter.

Forretningsmæssig prioritering af IT projekter. Case: Forretningsmæssig prioritering af IT projekter. Lars Fruensgaard 27. september 2012 15 år i IT branchen (EG, IBM, Globeteam) Forretningsoptimering, Business Intelligence og udbudsrådgivning 10+ år

Læs mere

Guide til IT projekter i den fællesoffentlige projektmodel

Guide til IT projekter i den fællesoffentlige projektmodel DEN FÆLLESOFFENTLIGE PROJEKTMODEL Guide til IT projekter i den fællesoffentlige projektmodel Dato: 22.06.2015 Version: 1.0 1 Projektledelse af it-projekter Denne guide tager udgangspunkt i særlige forhold

Læs mere

Fredericia Kommune Den sammenhængende arbejdsplads

Fredericia Kommune Den sammenhængende arbejdsplads Fredericia Kommune Den sammenhængende arbejdsplads Fra vision til virkelighed www.traen.dk Dem du skal høre på Mary Larsen Kommunikationschef Fredericia Kommune Michael Ibsen Manager Traen Lab Århus Gothersgade

Læs mere

Projektlederens guide til tilfredsstillende geoinformationsprodukter

Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide til tilfredsstillende geoinformationsprodukter Projektlederens guide er udarbejdet på baggrund af projektet: MobilGIS til natur- og arealforvaltere en web-baseret prototype. Projektet

Læs mere

ØU 100517 pkt. 06_01. Strategi for digitalisering og it-anvendelse i Hvidovre Kommune

ØU 100517 pkt. 06_01. Strategi for digitalisering og it-anvendelse i Hvidovre Kommune It med ny mening Strategi for digitalisering og it-anvendelse i Hvidovre Kommune Indhold Borgmesterens forord 3 Baggrund 4 Strategiens gyldighed og sammenhæng 5 Organisering af digitaliseringsarbejdet

Læs mere

Effektiv sagsbehandling og hurtig borgerservice

Effektiv sagsbehandling og hurtig borgerservice Effektiv sagsbehandling og hurtig borgerservice 360 Kommuneløsning Med udvidet borgerselvbetjening og tværgående digitale arbejdsgange er kommunen efterhånden blevet borgernes primære kontaktpunkt til

Læs mere

Fremtidens forskning og forskningsbiblioteket Resumé

Fremtidens forskning og forskningsbiblioteket Resumé Fremtidens forskning og forskningsbiblioteket Resumé Danmarks Elektroniske Fag- og Forskningsbibliotek Fremtidens forskning og forskningsbiblioteket Resumé Massive teknologiske forandringer inden for forskning,

Læs mere

TOM NYMANN. Kursets Undervisere. PRINCE2 Projektledelse. PRINCE2 Foundation & Practitioner

TOM NYMANN. Kursets Undervisere. PRINCE2 Projektledelse. PRINCE2 Foundation & Practitioner Tom er en af vores undervisere. Han er akkrediteret PRINCE2 underviser og har særlig stor erfaring med både teoretisk og anvendt projektledelse. Han er pædagogisk orienteret, og lægger vægt på at formidle

Læs mere

DEN LILLE SKARPE OM RAMMEARKITEKTUREN

DEN LILLE SKARPE OM RAMMEARKITEKTUREN DEN LILLE SKARPE OM RAMMEARKITEKTUREN HVORFOR EN FÆLLESKOMMUNAL RAMME ARKITEKTUR? Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, fordi Borgerne skal møde en nær og sammenhængende

Læs mere

Tjeklisten for bedre indtjening

Tjeklisten for bedre indtjening Tak fordi du har downloadet Den ultimative tjekliste for bedre indtjening. Manglende indtjening hænger ofte sammen med, at der er ting i dit workflow, du kan forbedre. En tjekliste er uvurderlig, for den

Læs mere

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder.

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder. It-strategi 1.0 Indledning Flere og flere forretningsprocesser i kommunerne stiller krav til it-understøttelse, og der er store forventninger til at den offentlige sektor hænger sammen inden for it-området.

Læs mere

Vejledning til proces for design af gevinstdiagram

Vejledning til proces for design af gevinstdiagram Januar 2014 Indhold 1. FORMÅL... 3 FORMÅLET MED DENNE PROCESVEJLEDNING... 3 2. GEVINSTDIAGRAM... 3 2.1. AKTIVITE TER... 4 DEFINER MÅLSÆTNINGER... 5 IDENTIFICER GEVINSTER... 5 IDENTIFICER RESULTATER, FORANDRINGSEVNER

Læs mere

Hvad gør Danmark for at lykkes med it-projekter og hvilken betydning har kompetencer? Ministeriernes projektkontor Christian Schade juni 2015

Hvad gør Danmark for at lykkes med it-projekter og hvilken betydning har kompetencer? Ministeriernes projektkontor Christian Schade juni 2015 Hvad gør Danmark for at lykkes med it-projekter og hvilken betydning har kompetencer? Ministeriernes projektkontor Christian Schade juni 2015 HVEM ER VI? PROFESSIONALISERING AF IT-PROJEKTER Fokus på risikofyldte

Læs mere

Coop Danmark. ServicePortal Implementering og erfaringer

Coop Danmark. ServicePortal Implementering og erfaringer Coop Danmark ServicePortal Implementering og erfaringer Julie, Peter og Lisbeth SIDE 1 Indhold Om Coop Baggrund og formål Lisbeth Projektet og erfaringer Peter Arbejdet i ServiceDesk Julie Effekt i ServiceDesk

Læs mere

Tag udgangspunkt i følgende spørgsmål

Tag udgangspunkt i følgende spørgsmål Projektets titel: Udfyldes af projektejer og projektleder. Læs inden du udfylder skabelonen: Svarene udgør den dokumentation projektet besluttes på baggrund af. Spørgsmålene er ment som inspiration til

Læs mere

HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact

HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact More than 3500 projects In control of 55 petabyte data 450 certified consultants More than 1.5M euro in training per year 55 PB,

Læs mere

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Servicebeskrivelse Økonomistyrelsen Marts 2011 Side 1 af

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere