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