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

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur OIO relateret til andre metoder og rammeværk Version 1.0 Tekniske og forretningsmæssige X1. Forretningsmæssige X2. Tekniske Strategi Forretning Teknik A1. relaterede udfordringer

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur FAQ Version 1.0 Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur Introduktion til OIO Enterprise Arkitektur metoden (OIO ) Version 1.0 Tekniske og forretningsmæssige X1. Forretningsmæssige X2. Tekniske Strategi Forretning Teknik A1. relaterede

Læs mere

Elektronisk samhandling i dansk offentlig sektor

Elektronisk samhandling i dansk offentlig sektor Elektronisk samhandling i dansk offentlig sektor v. Michael Bang Kjeldgaard IT- og Telestyrelsen Oslo 11. september 2008 Lessons learned Velfungerende ramme for koordinering Tilgang der matcher modenhedsniveau

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur De enkelte trin i OIO Enterprise Arkitektur metoden (OIO EA) Version 1.0 Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur OIO EA roller Version 1.0 Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Forretning Teknik A1. EArelaterede udfordringer A3. EA metodegrundlag

Læs mere

OIO Enterprise Arkitektur

OIO Enterprise Arkitektur OIO Enterprise Arkitektur OIO EA scenarier Version 1.0 Tekniske og forretningsmæssige trends X1. Forretningsmæssige trends X2. Tekniske trends Strategi Forretning Teknik A1. EArelaterede udfordringer A3.

Læs mere

It-arkitekturprincipper. Version 1.0, april 2009

It-arkitekturprincipper. Version 1.0, april 2009 It-arkitekturprincipper Version 1.0, april 2009 Fælles it-arkitekturprincipper Som offentlig it-chef, projektleder eller professionel, der arbejder med digitalisering, skal du træffe mange valg i en hektisk

Læs mere

Informationsforvaltning i det offentlige

Informationsforvaltning i det offentlige Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital

Læs mere

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT (EA) STRATEGY, BUSINESS AND IT ALIGNMENT AGENDA HVAD SKAL VI IGENNEM? FØR FROKOST Hvad er Enterprise Architecture (EA) Baggrunden for EA EA Rammeværk(er), den danske vinkel EFTER FROKOST Gennemgang af

Læs mere

System Arkitekt Practitioner

System Arkitekt Practitioner System Arkitekt Practitioner Kompetencebeskrivelsee DISAC Danish IT Society s Architectural Certification DANSK IT 2012 1 IT arkitekt Practitioner System Arkitekt Denne certificering repræsenterer det

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

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

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

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

Når selskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng.

Når selskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. IT Når selskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. Fra strategi til resultater i forsyningssektoren 2 Når selskaber har en klar IT-strategi og anskaffer

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

Arkitekturrapport:

Arkitekturrapport: <PROJEKTNAVN> Arkitekturrapport: Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt. Det er projektlederens

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

IT- og Arkitekturkonferencen 2009

IT- og Arkitekturkonferencen 2009 DIAS 1 IT- og Arkitekturkonferencen 2009 Rolf Sørensen, KMD A/S KORT OM KMD DIAS 2 _ Full it service provider - It til hele værdikæden: _Strategisk sparring, projektbeskrivelse og -ledelse, implementering,

Læs mere

BILAG 2: COWI DISPOSITION

BILAG 2: COWI DISPOSITION MARTS 2014 KL BILAG 2: COWI DISPOSITION (BILAG TIL DAGSORDENSPUNKT 5: OPERATIONALISERING AF FORSLAG VEDRØRENDE EN RESULTATORIENTERET FORRETNINGSARKITEKTUR PÅ BESKÆFTIGELSESOMRÅDET). ADRESSE COWI A/S Parallelvej

Læs mere

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Fundament Vision & Strategi Logik Rammearkitektur Fysik Udvikling/Implementering 2 13.10.2014 Fælles it-arkitekturstyring

Læs mere

Principper for IT-arkitektur IT-Arkitektur principperne er en formulering af de generelle principper, der gælder for digitaliseringen i Odense Kommune. Principperne skal sikre, at digitaliseringen i Odense

Læs mere

GLOBETEAM. SOA Seminar 19.06.2007

GLOBETEAM. SOA Seminar 19.06.2007 SOA Seminar 19.06.2007 Agenda Kl. 08.30 09.00 Registrering og morgenmad Kl. 09.00 09.15 Velkomst Kl. 09.15 09.30 Indledning Kl. 09.30 10.30 Hvad er SOA og hvad er Enterprise Arkitektur? Kl. 10.30 10.45

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

Arkitekturprincipper for Sundhedsområdet

Arkitekturprincipper for Sundhedsområdet Arkitekturprincipper for Sundhedsområdet - Ved anskaffelse af nye systemer Version 0.91 DIGITAL SUNDHED SAMMENHÆNGENDE DIGITAL SUNDHED I DANMARK Nationale principper ved anskaffelse af it-systemer At indføre

Læs mere

Nasjonal arkitektur Danske erfaringer. difi.no/arkitektur Klaus Vilstrup Pedersen

Nasjonal arkitektur Danske erfaringer. difi.no/arkitektur Klaus Vilstrup Pedersen Nasjonal arkitektur Danske erfaringer difi.no/arkitektur 31.08.16 Klaus Vilstrup Pedersen Arkitektur Guide (DK) http//arkitekturguiden.digitaliser.dk/ Rammeværk OIO-EA / EIF-EIRA Tjeklister til brug i

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

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

Governance - borgervendt selvbetjening

Governance - borgervendt selvbetjening Governance - borgervendt selvbetjening KL netværksmøde, april 2014 /Anna Sofie Almegaard 1 Hvad sker i Københavns Kommune Historien bag Organisering og samarbejde Governance overblik over løsninger, principper,

Læs mere

Bilag 1 - Kommissorium for Kommunernes It-Arkitekturråd

Bilag 1 - Kommissorium for Kommunernes It-Arkitekturråd Besluttet 18. august 2014 Bilag 1 - Kommissorium for Kommunernes It-Arkitekturråd Baggrund Der investeres massivt i digitalisering af den kommunale sektor. Der er forventning og krav om, at digitaliseringen

Læs mere

Erhvervsudvalget 2009-10 ERU alm. del Bilag 47 Offentligt. Bilag. Økonomi- og Erhvervsministeriet. København, den 9. november 2009.

Erhvervsudvalget 2009-10 ERU alm. del Bilag 47 Offentligt. Bilag. Økonomi- og Erhvervsministeriet. København, den 9. november 2009. Erhvervsudvalget 2009-10 ERU alm. del Bilag 47 Offentligt Bilag Økonomi- og Erhvervsministeriet. København, den 9. november 2009. a. Økonomi- og Erhvervsministeriet anmoder om Finansudvalgets tilslutning

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

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

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS

Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS NOTAT Bilag 9 - Opsamling på høringssvar fra netværket til Arkitekturrapport for KITOS (Bilag til dagsordenspunkt 10, Arkitekturrapport for KITOS) Lars Nico Høgfeldt, Odense Kommune Generel indledning

Læs mere

FORARBEJDET FOR EN LØNSOM AX2012 OPGRADERING / REIMPLEMENTERING VÆRKTØJET TIL EFFEKTIVISERINGSPROJEKTER DIAGNOSTIC

FORARBEJDET FOR EN LØNSOM AX2012 OPGRADERING / REIMPLEMENTERING VÆRKTØJET TIL EFFEKTIVISERINGSPROJEKTER DIAGNOSTIC 1 FORARBEJDET FOR EN LØNSOM AX2012 OPGRADERING / REIMPLEMENTERING VÆRKTØJET TIL EFFEKTIVISERINGSPROJEKTER DIAGNOSTIC John T. Hummelgaard, Salgs- & Marketingdirektør Maj 2013 IMPLEMENTERINGEN AF MANGE ERP

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

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Kommissorium for Kommunernes it-arkitekturråd

Kommissorium for Kommunernes it-arkitekturråd Godkendt 3. oktober 2011 Kommissorium for Kommunernes it-arkitekturråd Baggrund En helt ny æra for it-understøttelsen af den kommunale sektor er indledt med salget af KMD og i forbindelse med den netop

Læs mere

SAS Institute CIO networking

SAS Institute CIO networking SAS Institute CIO networking Torsdag den 30. oktober Underdirektør Ejvind Jørgensen Rambøll Management Consulting Slide 1 Udvalgte temaer Forretningsudvikling og prioriteringer CIO en og relationen til

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

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

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

Når forsyningsselskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng.

Når forsyningsselskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. IT Når forsyningsselskaber har en klar IT-strategi og anskaffer systemer med fokus på behov, værdi og sammenhæng. Fra strategi til resultater i forsyningssektoren 2 Når forsyningsselskaber har en klar

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

Arkitektur i projekter

Arkitektur i projekter lederdag i staten, Eigtveds Pakhus, den 3. oktober 2013 Hvad betyder det, at vi kan indarbejde it-arkitektur i vores projekter tidligt, og hvordan kan vi gøre det?, enterprise arkitekt, Dagsorden Præsentation

Læs mere

2. Fødevareministeriet er en koncern

2. Fødevareministeriet er en koncern Ministeriet for Fødevarer, Landbrug og Fiskeri Fødevareministeriets effektiviseringsstrategi 1. Indledning 2. udgave af Fødevareministeriets effektiviseringsstrategi er udarbejdet i 2007. Effektiviseringsstrategien

Læs mere

Case: Ekspertbud. 1) Øget konkurrence som følge af flere aktører på markedet, 2) Koordineringsproblemer af egne ressourcer.

Case: Ekspertbud. 1) Øget konkurrence som følge af flere aktører på markedet, 2) Koordineringsproblemer af egne ressourcer. Case: Ekspertbud Ekspertbud A/S er et succesfuldt firma inden for budforsendelser. Firmaet har 600 ansatte, hvoraf 500 er chauffører. Firmaet blev etableret i 1989, og er vokset stærkt siden. Firmaet oplever

Læs mere

Introduktion til Digital Post. Februar 2016

Introduktion til Digital Post. Februar 2016 Introduktion til Digital Post Februar 2016 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital Post og hvad der skal

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

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

Bilag 1: Arkitekturrapport, EDS Hjælpemidler

Bilag 1: Arkitekturrapport, EDS Hjælpemidler Bilag 1: Arkitekturrapport, EDS Hjælpemidler (Bilag til dagsordenspunkt 2, Arkitekturrapporter fra Effektiv Digital Selvbetjening) Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug

Læs mere

STRATEGI OG DIGITALISERING HÅND I HÅND

STRATEGI OG DIGITALISERING HÅND I HÅND ADMINISTRATION OG DIGITALISERING STRATEGI OG DIGITALISERING HÅND I HÅND STRATEGI OG DIGITALISERING HÅND I HÅND KL driver i samarbejde med Implement A/S et netværk - Strategi og Digitalisering hånd i hånd

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

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

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

Seminar d. 19.9.2013. Klik for at redigere forfatter

Seminar d. 19.9.2013. Klik for at redigere forfatter Seminar d. 19.9.2013 Klik for at redigere forfatter M_o_R En risiko er en usikker begivenhed, der, hvis den indtræffer, påvirker en målsætning Risici kan dele op i to typer Trusler: Der påvirker målsætningen

Læs mere

Erfaringer med Service Orienteret Arkitektur

Erfaringer med Service Orienteret Arkitektur Erfaringer med Service Orienteret Arkitektur ved Adm. direktør Niels Henrik Sodemann, Ementor Danmark A/S nhs@ementor.dk, +45 7242 8244 PA Consulting 21.6.2007, Tuborg Boulevard 5, DK-2900 Hellerup SOA

Læs mere

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT

ENTERPRISE ARCHITECTURE (EA) STRATEGY, BUSINESS AND IT ALIGNMENT (EA) STRATEGY, BUSINESS AND IT ALIGNMENT EFTER FROKOST Del 2 - EA Use case Når forretningen driver teknikken. EA USE CASE Dansk produktionsvirksomhed Producerer og sælger elektronikkomponenter til Droner

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

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

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

Risikovurdering til aktstykke

Risikovurdering til aktstykke Finansudvalget 2010-11 Aktstk. 99, endeligt svar på 17 spørgsmål 1 Offentligt PROASK Organisation Risikofaktor Anvendes der en teknisk løsning, som organisationen ikke har kendskab til (høj) eller en kendt

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

GENUDBUD AF NEMREFUSION. 28. november 2013

GENUDBUD AF NEMREFUSION. 28. november 2013 GENUDBUD AF NEMREFUSION 28. november 2013 Agenda Formål med genudbuddet og overordnede målsætninger Funktionalitet og værdi System design drift support Selvbetjeningskomponent (option) Tidsplan/udbudsform

Læs mere

Semantik, tak! Semantik og modelbaseret standardisering i OIO. 2. april 2009, IT-arkitekturkonferencen 2009

Semantik, tak! Semantik og modelbaseret standardisering i OIO. 2. april 2009, IT-arkitekturkonferencen 2009 Semantik, tak! Semantik og modelbaseret standardisering i OIO 2. april 2009, IT-arkitekturkonferencen 2009 Jan Brown, Kontoret for Standardiserings- og Arkitekturpolitik IT- og Telestyrelsen, Videnskabsministeriet

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

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

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

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

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

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

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

Timengo. Digitalisering med en Microsoft platformen Kenneth Wohlers, Timengo. Timengo

Timengo. Digitalisering med en Microsoft platformen Kenneth Wohlers, Timengo. Timengo Digitalisering med en Microsoft platformen Kenneth Wohlers, Agenda Sikker post Nye muligheder Vores løsning - VMG Scenarier Teknisk overblik Hvad er Sikker post Teknologi Certifikater Standarder Formål

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

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

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

Notat. Omstilling til edag - handlingsplan. Projektets formål og succeskriterier. edag arbejdsgruppen. IT-Kontoret. edag i Aalborg Kommune

Notat. Omstilling til edag - handlingsplan. Projektets formål og succeskriterier. edag arbejdsgruppen. IT-Kontoret. edag i Aalborg Kommune Notat Til: edag arbejdsgruppen Kopi til: Fra: IT- Dato: 28.04.2003 Vedr.: edag i Aalborg Kommune Mandag d. 1. september 2003 er fastsat som edag for alle offentlige myndigheder. edag er aftalt mellem regeringen,

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

Identity og Access Management

Identity og Access Management Identity og Access Management Udfordringen Hvor er vi i dag Hvordan griber vi det an 06-09-2013 1 Udfordring Når en medarbejder skifter stilling så tildeles en ny netværksidentitet (brugerid) Arbejdskrævende

Læs mere

Projektplan Syddjurs Smart Community

Projektplan Syddjurs Smart Community Projektplan Syddjurs Smart Community Dokument: Projektplan Version: 1.1 Udgivelsesdato: 9. marts 2016 Udarbejdet af: MC Kontrolleret af: JT Godkendt af: MC Indhold 1 Indledning... 3 1.1 Projektets titel...

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

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Bilag 1 Vurdering af økonomiske konsekvenser af beslutningsforslag B 103 1. Indhold i beslutningsforslag B 103 Det overordnede

Læs mere

Bilag 1 - a. It og Telestyrelsens principper 15 Skarpe 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Få styr på forretningsg angene

Bilag 1 - a. It og Telestyrelsens principper 15 Skarpe 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Få styr på forretningsg angene Bilag 1 - a 1 Ét hospital Der samarbejdes koordineres om it i DNU inden for områder hvor øget forretningsværdi eller reducerede omkostninger kan realiseres 2 It styring er en ledelseopgave DNU ledelsen

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

Metodehåndbog. Processer. Udarbejdet i fællesskab mellem KL og KOMBIT

Metodehåndbog. Processer. Udarbejdet i fællesskab mellem KL og KOMBIT Metodehåndbog Processer Udarbejdet i fællesskab mellem KL og KOMBIT Indhold Introduktion... 3 Procesmodellering... 3 Qualiware... 4 Notation for Processer... 4 Pool... 5 Lane... 6 Aktivitet... 6 Hændelse...

Læs mere

Teknologi arkitekt. Practitioner ------------------------- Kompetencebeskrivelse

Teknologi arkitekt. Practitioner ------------------------- Kompetencebeskrivelse Teknologi arkitekt Practitioner ------------------------- Kompetencebeskrivelse 2012 DISAC Danish IT Society s Architectural Certification DANSK IT 2012 DETTE DOKUMENT MÅ IKKE KOPIERES UDEN UDTRYKKELIG

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

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

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

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

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0.

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0. Side 1 af 12 19. september 2008 Autencitetssikring Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning Version 1.0. Denne vejledning introducerer problemstillingen omkring

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

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

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

Vi vil meget gerne arbejde med gevinstrealisering, men der er så mange udfordringer og modstand. Survey om Business Case og Gevinstrealisering

Vi vil meget gerne arbejde med gevinstrealisering, men der er så mange udfordringer og modstand. Survey om Business Case og Gevinstrealisering Vi vil meget gerne arbejde med gevinstrealisering, men der er så mange udfordringer og modstand Survey om Business Case og Gevinstrealisering Mads Lomholt Reference Peak 2013 Brug af undersøgelsen er tilladt

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

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

Bilag 1: Ekstrakt af forretningsarkitekturanalyse af digital understøttelse af tværgående komplekse patientforløb

Bilag 1: Ekstrakt af forretningsarkitekturanalyse af digital understøttelse af tværgående komplekse patientforløb Bilag 1: Ekstrakt af forretningsarkitekturanalyse af digital understøttelse af tværgående komplekse patientforløb (Bilag til dagsordenspunkt 2, Orientering om Arkitekturanalyse på sundhedsområdet af komplekse

Læs mere