OIO Enterprise Arkitektur - digitaliser · Michael Bang Kjeldgaard Lars Wilkens Henriksen Jens Peter Koch / Emil Broholm Aalborg 29. oktober 2007 Århus 30. oktober 2007 København

OIO Enterprise Arkitektur

Michael Bang KjeldgaardLars Wilkens HenriksenJens Peter Koch / Emil Broholm

Aalborg 29. oktober 2007Århus 30. oktober 2007København 5. november 2007Odense 5. november 2007

Agenda

Introduktion – fortæl ganske kort Kender og bruger i Enterprise Arkitektur

metoder? Forventninger til i dag?

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?

Sagsbehandler

Ansøgning

BorgerIndgiv ansøgning

Økonomi

Kontrol

Kontrolleransøgning forformalia

Formaliaoverholdt?

Sagsbehandling

ja

Afslag

Ansøgningimødekommet?

Start udbetaling

Kontrol

Udbetaling

Modtag udbetaling

Start

Erudbetaling

iorden?

Ja

Afslag

Begrund og sendafslag

Stop

Nej

Gentoptagsagsbehandling

Nej

Ja

Nej

B4. Forretningsprocesser

B1. Forretningsobjekter

Borger

Sagsbehandler

Systemadministrator

CPR/CVR/BBR

Henvendelse

Opretborgerkonto

Opret sag

Informer om atsag er oprettet

Sagsbehandling

Udbetaling

Kontrol

Økonomisystem

Vis sagsforløb

Borgerportal

Sagsbehandlingssystem

B5. UseCases

Trin Beskrivelse Aktører Services Objekter 1. Borger klikker på

”sagsoversigt” i Borgerportal-menu.

Borger Borgerportal

Kunde.HentKundeStamdata( Kunde_ID)

Borger

2. Borger t ilgår detaljerede oplysninger om de enkelte sager

Borger Borgerportal Sagsbehandlings-system

Sag.Hent [Journalnummer] (Henter oplysninger om sagen) 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.Dokument_List [Aktnummer] (Viser evt. dokumenter journaliseret på hændelsen)

Borger Sag Hændelse

B5. UseCases-detaljeret -beskrivelse

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.

Input Borgerens identifikation Dato

Output 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 22-06 per døgn. Borgeren have nem adgang til at indsende opdateringer til oplysningerne.

Noter Borgeren skal kunne se sine informationer via en sikker, krypteret forbindelse.

UseCase reference 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

B3. Forrretnings-services

C3. Service-arkitektur

Teknisk service Hent_Borgerstamdata Beskrivelse Henter borgerens stamdata i kunderegisteret. I


Input KundeNøgle Dato (Date)

Output KundeStamdata Fejl UkendtKunde

UgyldigDato

Teknisk SLA 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 Noter UseCase reference 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

Service reference Borger-stamdata

Agenda

Hvad er enterprise arkitektur?

ForretningTeknologiBroen imellem de to

Skal altid være Forståelig Opdateret I brug

=> Behov for EA governance

Kilde: Danmarks Statistik februar 2007

Barrierer for digital forvaltning 2006

Hvidbogens strategiske kobling mellem forretning og teknologi

Tid og gennemførtearkitekturprojekter

Katalog over standarder

OIOXML & ISB

Brugerstyringsreferencemodel

OCES / digital signatur

Sektorstandardering

SOA infrastruktur / OIOSI

FESD, eFaktura, NemKonto

2007

Softwarebørs

DS 484

Hvidbog om it-arkitektur

OIO EA ramme / arkitekturguide

integrationsmodel for portaler

Håndbog om it-arkitektur

Roadmap for det fælles arkitekturarbejde (2001 -

Fælles løsning Brugerstyring

FESD standarder 2

20032002 2004 2005 2006 201020092008

Aftale om udveksling af data

Kortlægning B 103 krav om standarder

Arkitekturkrav

Digital signatur 2

Domænebestyrelsers handlingsplaner

Adm. fællesskaber

eDag1 + 2

ISB2

Modenhed, sammenhæng, Effektivitet og nytteværdi



OIOXML & ISB



Sektorstandardering



2007

Softwarebørs

DS 484





OIO arkitekturmetodevejledning (2003)


FESD standarder 2

20032002 2004 2005 2006 201020092008



Arkitekturkrav

Digital signatur 2


Adm. fællesskaber

eDag1 + 2

ISB2




OIOXML & ISB



Sektorstandardering



2007

Softwarebørs

DS 484







FESD standarder 2

20032002 2004 2005 2006 201020092008



Arkitekturkrav

Digital signatur 2


Adm. fællesskaber

eDag1 + 2

ISB2





OIOXML & ISB



Sektorstandardering



2007

Softwarebørs

DS 484







FESD standarder 2

20032002 2004 2005 2006 201020092008



Arkitekturkrav

Digital signatur 2


Adm. fællesskaber

eDag1 + 2

ISB2




Principper og styring

Tekniske og forretningsmæssige trends

Strategi

X1.Forretnings-

mæssige trends

A1.EA-

relaterede udfordringer

X2.Tekniske

trends

Y5.Kontrakt og aftaleforhold

A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

Forandring

E1.Migrations-

strategi

E2.Migrations-

plan

E3.Konsekvens-

analyse

Y3.EA

governance

B1.Forretnings-

objekter

B6.Workflow

B4. Forretnings-processer

B2. Lokationer/organisation

B5. UseCases

B3.Forretnings-

services

C2.Applikationsarkitektur

C4.Teknologiarkitektur

C3.Servicearkitektur

C1.Informationsarkitektur

Y2. Budget- og ressource-

styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger



OIOXML & ISB



Sektorstandardering



2007

Softwarebørs

DS 484







FESD standarder 2

20032002 2004 2005 2006 201020092008



Arkitekturkrav Digital signatur 2


Adm. fællesskaber

eDag1 + 2

ISB2






Strategi

X1.Forretnings-

mæssige trends

A1.EA-


X2.Tekniske

trends


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

Forandring

E1.Migrations-

strategi

E2.Migrations-

plan

E3.Konsekvens-

analyse

Y3.EA

governance

B1.Forretnings-

objekter

B6.Workflow



B5. UseCases

B3.Forretnings-

services






styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

Samordnet model der overordnet kobler OIO EA til forskellige metoder, fx FOKUS, DS 484, ITIL, Prince 2

Eksempler på brugere af OIO EA

Københavns KommuneOdense KommuneÅrhus KommuneKLDanske Regioner / EPJ arkitektur KMSOIO-udvalget for socialområdetFESD 2ISB 2ITST.dk

Agenda

OIO Arkitekturramme – elementer

Arkitekturramme Enterprise arkitekturmetode

Introduktion Trinbeskrivelser

EA Scenarier EA Rammeværk Kompetencer og roller

Profilværktøj Mapning til andre metoder Klassifikation/taksonomier Downloadable dokumenter Engelsk Introduktion FAQ Arkitekturbibliotek



Strategi

X1.Forretnings-

mæssige trends

A1.EA-


X2.Tekniske

trends


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

Forandring

E1.Migrations-

strategi

E2.Migrations-

plan

E3.Konsekvens-

analyse

Y3.EA

governance

B1.Forretnings-

objekter

B6.Workflow



B5. UseCases

B3.Forretnings-

services






styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

TeknologiApplikationInformationForretningStrategi

Fysisk

Logisk

Konceptuelt

Strategier Forretningsstrukturer Applikationsarkitektur TeknologimodelObjektmodeller

Processer Forretningslogik TeknologistrukturLogiske datamodellerPrincipper

Workflows Applikationsdesign TeknologilandskabFysiske datamodellerForretningsregler

Styrings-rammer

Trends og projektgrundlag Gap analyse Forandring Governance Styring

Overblik

OIO EA metoden

Metode trin for trin med eksempler og tips

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 projekt-portefølje

OIO EA’s trin ikke ”nye” – men giver en sammen-hæ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

Brug af OIO EA metoden

Fuld EA Delvis EAIT-projekt

IT-udbud

Koncern informations-arkitektur

Fællesoffentlig infrastruktur

Konsolidering af arbejdsgange

ved fusion

Konsolidering af koncerninfrastruktur

Datainfrastruktur for sektor

OIO EA scenarier

EA scenarie: Dir. For Fødevareerhverv (DFFE)

Strategi

A1.EA-


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

Forandring

E1.Migrerings-

strategi

E2.Migrerings-

plan

E3.Konsekvens-

analyse

B1.Forretnings-

objekter

B6.Workflow



B5. UseCases

B3.Forretnings-

services







Y3.EA

governance


styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

Fremtidigearkitektur

Nuværendearkitektur

DFFE krav

Grundlag for udbud

Fødevaresektorbegrebsmodel

DFFE term

Begrebsmodel Services OperationerDomænemodel

Gennemgående EA eksempel

Tekniske og Forretningsmæssige Trends

Strategi

X1.Lovmæssige

bindinger

X2.Forretnings-

aspekter

X3.Interessent-

forhold

A1.EA-

relateredeudfordringer

X4.Eksterne

principper ogpolitikker

X5.Kontrakt ogaftaleforhold

A2.EA

governancestrategi

A4.Projektcharter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3.Gap analyse

Forandring

E1.Migrerings-

strategi

E2.Migrerings-

plan

E3.Konsekvens-

analyse

E4.EA

governance

B1.Forretnings-

objekter

B6.Workflow

B4.Forretnings-processer

B2.Lokationer/organisation

B5.UseCases

B3.Forretnings-

services

C1.Nuværendeit-arkitektur

- Information- Applikation- Service- Teknologi

C3.Applikations-

arkitektur(fremtidig)

C5.Teknologi-arkitektur(fremtidig)

C4.Service-arkitektur(fremtidig)

C2.Informations-

arkitektur(fremtidig)

Principper og Styring

Y1.OIO EAmetode-udvikling

Y3.Budget- ogresource-

styring

Y2.Drifts-

situation

OIO EA metode – gennemgående eksempel

EA scenarie: DFFE – trintilpasning (forretningsprocesser)

EA scenarie: DFFE-specifikke skabeloner

Relation til andre metoder og rammeværk

OIO EA er en fuld EAmetode der mapper til andre metoder og rammeværk

Guiden indeholder mapninger til

TOGAFFEAFZachman

Figuren viser hvordanSKATs arkitekturmetode trin relaterer sig til OIO EA trinene

Overbliks-niveau

’

1. Procesoverblik


’

2. Generelle processer

B6.Workflow

1. Domænegruppe

2. Centrale begreber

Konkretniveau

’

3. Processer

’

4. Aktiviteter

3. Overordnet begrebsmodel

(vigtigste egenskaber)

4. Detaljeret begrebsmodel

’

5. Services 5. Udsnit af begrebsmodel

Processer Begreber

B1.Forretnings-

objekter

B1.Forretnings-

objekter

C1.Informations-

arkitektur

C1.Informations-

arkitektur

C1.Informations-

arkitektur

B6.Workflow

B5. UseCases

B3.Forretnings-

services

C3.Service-arkitektur

OIO EA relateret til andre metoder & rammeværk

OIO EA roller

Enterprise arkitektprofil

OIO EA kompetencer og profiler

Værktøj til vurdering af arkitekturkompetencer og sammensætning af teams

http://ea.oio.dk/download

OIO EA rammeværk og klassifikation

OIO arkitekturrammeværk – en ”bogreol”


Fysisk

Logisk

Konceptuelt

Strategier Forretningsstrukturer Applikationsarkitektur TeknologimodelObjektmodeller

Processer Forretningslogik TeknologistrukturLogiske datamodellerPrincipper

Workflows Applikationsdesign TeknologilandskabFysiske datamodellerForretningsregler

Styrings-rammer

Trends og projektgrundlag Gap analyse Forandring Governance Styring

OIO EA reol - hyldeindhold

OIO EA reol med dokumenterS

amm

enhængende kobling af

metode og leverancer


Fysisk

Logisk

Konceptuelt

Strategier

A5.1 Vision, mål, strategier, KSFerA5.2 Metrikker, KPIerA5.3 SWOT, business drivers, 5 forcesA5.5 Interessentanalyse

Forretningsstruktur

B2.1 LokationsmodelB2.2 OrganisationsmodelB2.3 AktørmodelB3.1 ForretningsservicesB3.2 Forretningsservices-Lok. mapB3.3 Forretningsservices-Org. map

Applikationsstrategi

C2.3 Applikation infrastruktur mønstreC2.6 Integrationsstrategi/mønstre

Teknologistrategi

C4.1 Teknologi referencemodel

Objektmodeller

B1.1 ForretningsobjekterB1.2 Forretningsobjekters relationerB1.3 Forretningsspørgsmål

Processer

B4.1 ProcesmodelB4.2 Proces-evalueringB4.3 Proces-forretningsobjekt map B4.4 Proces-lokationsmapB4.5 Proces-organisationsmap

ApplikationsstrukturC2.1 ApplikationkatalogC2.2 Applikation-Information map C2.4 Applikation-Proces map C2.5 IntegrationskatalogC2.7 Applikation-Integration views B5.1 Use CasesC3.1 Serviceoversigt

Teknologistruktur

C4.2 ABB (Arkitektur ByggeBlokke)C4.3 System topologierC4.4 Udvidede system topologier

Logiske datamodeller

C1.1 Informationsobjekter i LDMC1.2 Data DistributionC1.3 Database oversigt

Principper

A6.1 It-principper, rationale, implikationer

Workflows

B6.1 WorkflowsB6.2 Forretningsregler tilknytttet workflows

Applikationsdesign

C3.2 Komponentopdelt applikationslandskabC3.3 (Web)service-forretningsservice map

Teknologilandskab

C4.5 Teknologi inventory

Fysiske datamodeller

C1.4 Fysisk datamodel, incl. OIOXML

Forretningsregler

A5.4 Forretningsregler

Styrings-rammer

Trends og projektgrundlag

X1.1 Forretningsmæssige trendsX2.1 Tekniske trendsA1.1 EA-relaterede udfordringerA3.1 OIO EA metode (tilpasset)A4.1 Projekt charterA4.2 Business case

Gap analyse

D1.1 Restriktioner, konsekvenser og alternativerD1.2 RisikoanalyseD2.1 Muligheder, vigtighed og indsatsD3.1 Gap analyse

Forandring

E1.1 MigreringsstrategiE2.1 MigreringsplanE3.1 Konsekvensanalyse

Governance

A2.1 EA governance strategiY3.1 EA governance beskrivelse

Styring

Y1.1 DriftY2.1 Budget og ressourcerY4.1 Lovmæssige bindingerY5.1 Kontraktforhold

Andre DokumenttyperDenne kategori inde-holder dokumenterDer dækker mange af de ovenståendeområder, samt mere

Foranalyse og it strategiKan indeholde mange af leverancerne ovenforA1.1 EA-relaterede udfordringerA6.1 it-principper, rationale, implikationer

Kravspecifikationer

Kan indeholde mange af leverancerne ovenfor, samlet i et dokument

Projektledelse og - styringKan indeholde mange af leverancerne ovenfor, samlet i et dokument, herunderA3.1 OIO EA metode (tilpasset)A4.1 EA projekt charterE1.1 MigreringsstrategiE2.1 Migreringsplan

Implementering og testIndeholder dokumenter der ikke direkte er OIO EA-relaterede, men som alligevel kan være af interesse. Herunder:DesignspecifikationerTestplanerTestdokumentation

SikkerhedKan indeholde mange af leverancerne ovenfor, samlet i et dokument der specificerer komplekse sammenhænge,, herunderC4.4 Udvidede system topologier

OIO EA reol med standarder

Dokumenter og andre ressourcer

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 value-add

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

Nyt i OIO EA – arbejdsmodel

Projekt

Organisation Metode

Dokumentationsramme


Fysisk

Logisk

Konceptuelt

Strategier


Forretningsstruktur




Teknologistrategi


Objektmodeller


Processer



Teknologistruktur




Principper


Workflows


Applikationsdesign


Teknologilandskab




Forretningsregler


Styrings-rammer


X1.1 Forretningsmæssige trendsX2.1 Tekniske trendsA1.1 EA-relaterede udfordringerA3.1 OIO EA metode (tilpasset)A4.1 EA projekt charter

Gap analyse


Forandring


Governance


Styring




Strategi

X1.Forretnings-

mæssige trends

A1.EA-


X2.Tekniske

trends


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

Forandring

E1.Migrerings-

strategi

E2.Migrerings-

plan

E3.Konsekvens-

analyse

Y3.EA

governance

B1.Forretnings-

objekter

B6.Workflow



B5. UseCases

B3.Forretnings-

services






styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

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

Nyt i OIO EA

Bedre gennemgående eksempel Eksempel og skabelon lægges op

Business case tilføjet (A4.2) – PRINCE2 stilChange control aktiveret

# Change request Stillet af Dato Kategori Område Estimat(timer)

Anbefaling Rationale / løsning AK Konklu-sion

Dato Status

1 Business caseIndfør business case som eksplicit leverance

LWH 11.09.07 Mellem A4 - A5 2 Accepter Business cases bruges i flere projekter, og OIO EA vejledning (med referencer til andre dokumenter) herom vil være nyttigt.

Der indføres et trin/en leverance A4.2 Business caseBusiness case nævnes måske i trin A5, men ikke som særskilt leverance.

n Accep-teret

26.09.07 Udestår(Kun A5)

2 A5 inputA5 skal være input til trin B1 og B4, og brugen af prioriteringer forklares bedre.

LWH 19.09.07 Mellem B1, B4 4 Accepter A5 hælper til at prioritere n Åben 19.09.07 Udestår

3 A4 EA. Projekt charterÆndres til "A4. Projekt charter"

LWH/MBK 26.09.07 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

Trin ændres til A4. Projekt charterLeverance A4.1hedder du Projekt charter

n Accep-teret

28.09.07 Imple-menteret

4 Flere røde trådeBedre forklaring til de røde tråde - både på dokumentform og i præsentationer.

LWH 28.09.07 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 Strategi-Processer-Applikationer)

n Åben

Nyt i OIO EA – den røde tråd i forretnings- og teknikmodelleringen(eks.: SOA tilgang)

Sagsbehandler

Ansøgning


Økonomi

Kontrol


Formaliaoverholdt?

Sagsbehandling

ja

Afslag


Start udbetaling

Kontrol

Udbetaling

Modtag udbetaling

Start

Erudbetaling

iorden?

Ja

Afslag


Stop

Nej


Nej

Ja

Nej



Borger

Sagsbehandler

Systemadministrator

CPR/CVR/BBR

Henvendelse

Opretborgerkonto

Opret sag


Sagsbehandling

Udbetaling

Kontrol

Økonomisystem

Vis sagsforløb

Borgerportal


B5. UseCases



Borger Borgerportal


Borger
















B3. Forrretningsservices






UgyldigDato





Nyt i OIO EA – kurser/seminarerEn 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

Agenda

Agenda

Bemærkninger til OIO EA

OIO EA er en ramme – tillempes altid behovet

Man gør ikke alting 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

Rækkefølgen er ikke fastlagt … men der er ”best-practices”

– fx ”to-be” forretnings-arkitektur før ”to-be” teknik-arkitektur

Man søger at parallelisere Man har iterationer, hvor

senere leverancer giver tilbageløb til tidligere

20-80% regel God ide med en gennem-

gående enterprise arkitekt Organisationens involvering

fra start!


X1.Forretnings-

mæssige trends

X2.Tekniske

trends

OIO EA metode – Tekniske og forretningsmæssige trends

Der identificeres hvilke forretningsmæssigetendenser der kan påvirke forretningen – såsom nye ønsker fra borgere, virksomheder og andre interessenter.

Der identificeres nye tekniske tendenser der åbnermuligheder for at forretningenkan nå sine interessenter pånye måder.

Generelt:

At følge trends, og tage initiativtil at de tænkes ind i Enterprise Arkitekturen, er en proaktiv indsats ogadskiller en EA tilgang fra en reaktivattitude 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.

Generelt: Eksterne faktorer man kun i begrænset omfang kan påvirke,men som man frivilligt kan reagere på.



Y3.EA

governance


styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

OIO EA metode – Principper og styring

Trinet skal sikre at enterprise arkitekturen formidles og koordineres med den dagligedrift – således at driften kommer med sitinput til arkitekturelle muligheder, og arbejder hen imod EA-målene

Trinet sikrer at foreslåede EA migreringsprojekter afstemmes medbudgetter og ressourcer.

En oversigt og løbende styringpå de lovmæssigebindinger der kanpåvirke enterprisearkitekturen

En styring af kontraktuelle forhold der skal tænkes ind i arkitekturen, og ikke mindst som enterprise arkitekturen skal søge at påvirke.

Generelt: Primært interne faktorer, man i større grad er i kontrol over, menstadig under eksterne rammer.

OIO EA metode – StrategiStrategi

A1.EA-


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Nogle (forretning eller teknik) foreslår etEA-relateret initiativ, på baggrund af nogle udfordringer, der dokumenteres.

Det sikres at der foreligger en governance strategiallerede inden projektstart, og at der er topledelsesopbakning til at sikre implementering af EA-arbejdets anbefalinger(ellers bliver det næppe en succes).

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.

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

A1. EA-relaterede udfordringerFormå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 interesseRationale:

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

A1. EA-relaterede udfordringerIndhold

EA-relateret údfordring

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 udfordringKategori Kan være "problem" eller "mulighed".Rub. Rubricering - en underkategoriserin, beregnet til gruppere

beslægtede udfordringer. Beskrivelse En beskrivelse af udfordringen. Gerne med en kort navngivning af

udfordringen. Se eksempel nedenfor.Interessent Den eller de gruppe mennesker der berøres af problemet/vil kunne

få gavn af muligheden.Konsekvens 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.

Vægt En indikation af hvor vigtigt det er at adressere udfordringen. Man kan bruge en skala 1-7, hvor 7 vægter mest, 1 mindst.

A1. EA-relaterede udfordringerEksempel

Eksempel# Kategori Rub. Beskrivelse Interessent Konsekvens Vægt

1 Problem F-G Manglende styring.Manglende fælles overblik og styring, ITU ikke altid inddraget i tide.

Alle Usammenhængende og inkonsistente beslutninger om it-projekter. En bedre koordination kunne spare 10% af it-udgifterne om 3 år.

6

2 Mulighed F-IA Borgervendt serviceansigtIntegreret udstilling af alle de informationer samlet har om borgeren

BorgereSagsbehandlere

Borger får større indsigt i sin situation, og adgang til denne 24x7.Kommunen sparer noget ekspeditionstid.

5

3 Mulighed T-AT Mobil arbejdsplads.Udstyre mobile medarbejdere med håndholdte enheder, med mobil adgang til fagapplikationer.

Mobile medarbejdere (hjemmehjælp, vej,…)Borgere

Bedre serviceBedre datakvalitetSparede dobbeltindtastninger

4

4 Problem F-G Svag topledelsesforankring.Svag forankring af arkitekturarbejde i topledelsen.

Alle Arkitekturbeslutninger realiseres ikke, med inkonsistens og dobbeltarbejde til følge.

6

5 Problem F-G Intet fælles sprogMangler fælles sprog for arkitekturtermer.

Alle Et fælles sprog vil fjerne usikkerhed i kommunikationen mellem de involverede, og sikre at arkitekturarbejdes formidles konsistent.

3

A3: EA metodegrundlag– OIO EA arbejdsmodel

Projekt

Organisation Metode

Dokumentationsramme


Fysisk

Logisk

Konceptuelt

Strategier


Forretningsstruktur




Teknologistrategi


Objektmodeller


Processer



Teknologistruktur




Principper


Workflows


Applikationsdesign


Teknologilandskab




Forretningsregler


Styrings-rammer


X1.1 Forretningsmæssige trendsX2.1 Tekniske trendsA1.1 EA-relaterede udfordringerA3.1 OIO EA metode (tilpasset)A4.1 EA projekt charter

Gap analyse


Forandring


Governance


Styring




Strategi

X1.Forretnings-

mæssige trends

A1.EA-


X2.Tekniske

trends


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

Forandring

E1.Migrerings-

strategi

E2.Migrerings-

plan

E3.Konsekvens-

analyse

Y3.EA

governance

B1.Forretnings-

objekter

B6.Workflow



B5. UseCases

B3.Forretnings-

services






styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

A3: EA metodegrundlag – DFFE

Projekt

Organisation Metode

Dokumentationsramme

Strategi

A1.EA-


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Forretning Teknik

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

Forandring

E1.Migrerings-

strategi

E2.Migrerings-

plan

E3.Konsekvens-

analyse

B1.Forretnings-

objekter

B6.Workflow



B5. UseCases

B3.Forretnings-

services







Y3.EA

governance


styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

Fremtidigearkitektur

Nuværendearkitektur

DFFE krav

Grundlag for udbud

Fødevaresektorbegrebsmodel

DFFE term

Begrebsmodel Services OperationerDomænemodel

Strateg i Processer Information Løsning Platform

Ejer

Arkitekt

Leverandør

Strategi

Politikker

Handlings-planer

Reference-model

Workflow

Forretnings-procesdesign

Begrebs-model

Logiskdatamodel

Fysiskdatamodel

ApplikationsArkitektur

SystemDesign

KomponentModel

ReferenceArkitektur

TekniskArkitektur

Fysiskteknologi

A4. Projekt charterA4.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)

A4. Projekt charterA4.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

Agenda


A1.EA-


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Det egentlige projekt begyndesmed 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-principperdokumenteres, som beslutningsgrundlag senere. Dette er en blanding af at dokumentere hvad der måtteeksistere, og at definere hvadder måtte mangle.

A5.1 Vision, mål og strategier

Vis ion

Mål

StrategierKritiske succesfaktorer

(KSFer)

Trin A.5 Vision, mål og strategierFlere 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 – forretningsstrategi-elementer konsolideres og dokumenteres – men nyudvikles ikke

A5.1 Vision, mål og strategier- Vision En høj-niveau

hensigtserklæring om hvad organisationens virke egentlig skal udrette

”Danmarks mest velfungerende digitale kommunale forvaltning”

Vis ion

Mål


(KSFer)

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

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.

Vis ion

Mål


(KSFer)

A5.1 Vision, mål og strategier- Strategi En tilgang til at realisere

sine mål Har typisk en horisont på

1-3 år

Vis ion

Mål


(KSFer)

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”

”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”

Vis ion

Mål


(KSFer)

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

Vis ion

Mål


(KSFer)

100% =Den bedsttænkelige, mulige situation

Den aktuellesituation

Vurder: Effekten for opnåelse af mål hvis dette gap lukkes?

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).

KSF-6: Der etableres en digital sagsbehandler-medarbejderportal (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 OIO-datastandarder (OIOXML) (4).

KSF-10: Der er en integrationsbus, så andre myndigheder kan koble sig på (3).

Vis ion

Mål


(KSFer)

A5.3 SWOT-analyseWeaknesses

Opportunities Threats

Strengths

- Højt it-niveau blandt borgerne i Danmark

- Stor udbredelse af bredbånd

- Lille kendskab til OIO-datastandarder

- Digital signatur ikke ret udbredt

- 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

- Større grad af sagsbehandlig flyttes over til borgerne

- Hurtigere sagsbehandlingstid ved bedre integrerede systemer

Weaknesses

Opportunities Threats

Strengths

A6. It-principper

Et it-princip: Udsiger noget

fundamentalt om organisationens it-brug.

Kan modsiges Er udtrykt i ikke-teknisk

sprog Samlet ca. 7-10

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

A6. It-principper - dokumentation It-princip:

<Tekst der kortfattet udtrykker princippet>

Rationale <Kort begrundelse for

princippet> Konsekvenser

<Uddybende bemærkninger om vigtige konsekvenser af princippet>

It-princip: Alt data er som udgangs-

punkt tilgængelig for alle Rationale

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

Agenda

Forretning

B1.Forretnings-

objekter

B6.Workflow



B5. UseCases

B3.Forretnings-

services

OIO EA metode – Forretning

Forretningssiden dokumenterer hvilke essentielle objekter (begreber) og relationer imellem disse, der indgår i forretningen.

Forretningen specificerer sin struktur, i form af eneller flere af disse:-lokationer (logiske steder)-organisation (ansvarsmæssige strukturer)-aktører (roller)

Forretningen defineres mere operationelt, iform af processer der udføres, og services der leveres til interessenter. Disse relateres ofte til hvilke forretnings-objekter de benytter, og/eller hvilke lokationerde udføres/leveres fra. Der foretages en prioritering af processers/services vigtighed, i forhold til strategierne.

De opgaver forretningen organisationen løser, kanspecificeres i UseCases, dersiger hvad der udføres, men ikke detaljeret hvordan. UseCases relateres ofte tilhvilke services de betjener sigaf/leverer, hvilke forretnings-objekter de bruger, hvilke aktører der udfører dem, osv.

Vigtige, komplekse processer og UseCases detaljeres til workflows, hvor man meredetaljeret beskriver hvordander arbejdes.

Generelt: I al fald ”TO-BE” situation,undertiden også ”AS-IS”.


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

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




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


Gode råd Der er typisk 10-15 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.



B3. Forretningsservices

Udtrykt i et sprog forretningen forstår Leder frem til en service-orienteret

arkitektur

B3. Den enkelte service: en kontrakt mellem servicemodtager og serviceudbyder

Forretningsmæssigt niveau: mellem slutbruger og forretnings-service-leverandør:

Tekniske niveau: mellem forretnings-serviceleverandør og teknisk leverandør

Service

Forretnings-services

Kunde

SLA forForretnings -

services

Service


Teknisk Servicearkitektur

SLA forTekniskeservices

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, …)

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 platforms-

uafhængige Fokus på interoperabilitet (nem

integration – integrationsbus) Brug af åbne standarder for data

og teknologi Specifikation og implementering

af en service er adskilte


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

B3. Forret-nings-services











B3. Eksempel: Kunde

Kunde

B3/C3. ”Kunde”-servicen som eksempel

Kunde

Opret KundeOpdater kunde automatiskOpdater kunde manuelt...Fo

rretn

ings

serv

ice

Kunde .OpretKunde .Stamdata_HentKunde .Stamdata_Ret

Tekn

olog

iser

vice

«Kundeservice»Kunde

+KundeID

«Kundeservice»Autorisationselement

+modtagerStatus+udstederStatus+startDato+slutDato+autorisationNiveau [0..1 no]+fuldAutorisationType [0..1 no]

«Skemaservice»«metaclass row »Ansøgning

+AnsøgningsID

«Kundeservice»Produktionsapparat

«Kundeservice»Areal

«Kundeservice»Besætning

«Kundeservice»Fartøj

«Kundeservice»Produktion

«Kundeservice»Kundeskifte

Indsender

1

0..*

Beskriver 11

Ejer1

0..*

Har modtaget

1

0..*

Foretages i f t1

1

Kommer fra

11

1

0..*

Har

1

0..*

1

0..*

relaterer til

0..*

0..*

«Sag service»Sag

+Sagsnummer

0..1Refererer til

0..*

1 indgår i 0..1

Har

0..*

1

1

*

1

0..*Harudstedt

Kunde

ServiceAgent

Autorisationer og fuldmagter

Base

Produktionsapparat Kundeskif te Metadata

UC 5.42 Opret kunde

UC 5.43 Automatiskopdatering af kunde

UC 5.07 OpretCVR- kunde

UC 5.08 OpretCPR- kunde

Sagsbehandler

Timer

CVR

CPR

GLR

«include»

«include»

«include»

«include»

«include»

«include»

UC 5.47 Genererudtræk af

kundedatabase tilESDH

ESDH

UC 5.15 Behandlanmodning om

oprettelse som kunde

«include»

UseCases


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


Sagsbehandler

Ansøgning


Økonomi

Kontrol


Formaliaoverholdt?

Sagsbehandling

ja

Afslag


Start udbetaling

Kontrol

Udbetaling

Modtag udbetaling

Start

Erudbetaling

iorden?

Ja

Afslag


Stop

Nej


Nej

Ja

Nej

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

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

B5. Use cases – elementer

Aktører – roller: Mennesker og systemer

Oversigtsdiagram: UseCases: opgaver der skal løses i samarbejde mellem aktørerne

Aktør1System1

Borger

Systemadministrator

Henvendelse

Opretborgerkonto

Borgerportal

B5. Use cases – beskrivelse

B5. Use cases

Borger

Sagsbehandler

Systemadministrator

CPR/CVR/BBR

Henvendelse

Opretborgerkonto

Opret sag


Sagsbehandling

Udbetaling

Kontrol

Økonomisystem

Vis sagsforløb

Borgerportal


B5. Use cases – overordnet beskrivelseUse Case navn Vis sagsforløb Version 1.0 Dato 29 maj 2007 Beskrivelse/formål 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 Borgeren er logget ind på kundeportalen. Slutbetingelser Stamdata samt liste over sager mv. v ises, med mulighed for at gå videre t il en

række skærmbilleder med mere detaljerede oplysninger. Forretningsregler Kun borgere registreret som boende i kommunen kan logge ind. Normalt flow Se nedenfor Alternativt flow Ingen Kommentarer Ingen

B5. Use cases - detaljeret



Borger Borgerportal


Borger





En rød tråd i forretnings- og teknikmodelleringen(eks.: SOA tilgang)

Sagsbehandler

Ansøgning


Økonomi

Kontrol


Formaliaoverholdt?

Sagsbehandling

ja

Afslag


Start udbetaling

Kontrol

Udbetaling

Modtag udbetaling

Start

Erudbetaling

iorden?

Ja

Afslag


Stop

Nej


Nej

Ja

Nej



Borger

Sagsbehandler

Systemadministrator

CPR/CVR/BBR

Henvendelse

Opretborgerkonto

Opret sag


Sagsbehandling

Udbetaling

Kontrol

Økonomisystem

Vis sagsforløb

Borgerportal


B5. UseCases



Borger Borgerportal


Borger






















UgyldigDato





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 arbejds-delingen mellem forskellige aktører (organisatoriske enheder) afdækkes og forankres.

Brug for eksempel UML activity diagram

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.

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.

Agenda

Agenda

Agenda

Teknik





OIO EA metode – Teknik

Forretningsobjekter fra i B1 videreudvikles til en egentlig informationsmodel. Der beskrives også database-strukturer og dataflows, på et logisk niveau.

Her defineres applikationsstruktur – hvilke applikationer findes/skal findes, og hvordan de er/fremover skal integreres. Der defineres både generelle valg (”mønstre”) ogkonkrete applikationer og integrationer. Applikationer/integrationer relateres ofte til dataflows.

Forretningens services (B3) videreudviklestil nogle tekniske services og operationer, ofte med SLAer. Services relateres ofte til de informations-objekter og applikationer der indgår i atrealisere dem.

Her defineres den underliggende infrastruktur derkan understøtte C1-C3. Dette omfatter:-Teknologi referencemodel-Konkrete teknologistrukturer, med byggeblokke og strukturer

Generelt: Både ”AS-IS” og ”TO-BE”situation beskrives.

C1. InformationsarkitekturOversigt 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

C1. InformationsarkitekturLeverancetyper

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

C1. InformationsarkitekturC1.1 Informations-objekter 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

C1. InformationsarkitekturC1.1 Informations-objekter 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

C1. InformationsarkitekturC1.4 Fysisk datamodel, inkl. OIOXML Links fra informations-model til

OIO-datastandard =

Semantik

Syntaks

+

C1. InformationsarkitekturC1.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)

C1. InformationsarkitekturC1.2 Data distribution Horisontal data fragmentering - al

information, men kun om udvalgte rækker

C1. InformationsarkitekturC1.2 Data distribution Vertikal data fragmentering – noget

information, om alle rækker

C1. InformationsarkitekturC1.2 Data distribution

CPR-register

Virksomhed

Rådhus

Bogholderi

Borger

Borgmesterkontor

Sagsbehandling

Indkøb

JobcenterJobcenter

Jobcenter

CR

RU

CRUD

RU

CR

C1. InformationsarkitekturC1.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 …

C2. ApplikationsarkitekturOversigt 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

C2. ApplikationsarkitekturLeverancetyper

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)

C2. ApplikationsarkitekturC2.7 Applikation-integration views (AS-IS)

CPR SKAT

SagsbehandlingA

BBR

ØkonomiA

SagsbehandlingB

ØkonomiB

filoverførsel

filoverførsel

filoverførsel

filoverførsel

Opslag v. DB query

filoverførsel

filoverførsel

filoverførsel

Arbedsstation

ArbedsstationSagsbehandler Arbedsstation Sagsbehandler

Manuelt opslagfiloverførsel

BorgerHenvendelse Henvendelse

Borger

filoverførsel

Manuelt opslag

Ny applikation

Eksisterende applikation, fortsætter uændret

Eksisterende applikation, udgår

Eksisterende applikation, modificeres

C2. ApplikationsarkitekturC2.7 Applikation-integration views (TO-BE)

CPR SKAT

Sagsbehandling

BBR

Økonomi

begivenhed begivenhed

filoverførsel

begivenhed

ArbedsstationSagsbehandler

BorgerHenvendelse

Borgerportal

Henvendelse

Integrationsbus

begivenhed

begivenhed

Ledelses-information

Opsamling

Opsamling

OpsamlingBeslutningstager

Ny applikation

Eksisterende applikation, fortsætter uændret

Eksisterende applikation, udgår

Eksisterende applikation, modificeres

Den røde tråd i OIO EA- baseret på processer

Sagsbehandler

Ansøgning


Økonomi

Kontrol


Formaliaoverholdt?

Sagsbehandling

ja

Afslag


Start udbetaling

Kontrol

Udbetaling

Modtag udbetaling

Start

Erudbetaling

iorden?

Ja

Afslag


Stop

Nej


Nej

Ja

Nej



C2.7 Applikation-integration views

Vis ion

Mål


(KSFer)

CPR SKAT

Sagsbehandling

BBR

Økonomi

begivenhed begivenhed

filoverførsel

begivenhed

ArbedsstationSagsbehandler

BorgerHenvendelse

Borgerportal

Henvendelse

Integrationsbus

begivenhed

begivenhed


Opsamling

Opsamling

OpsamlingBeslutningstager

A5. Vision, mål og strategier

C4. Teknologiarkitektur

C3. ServicearkitekturOversigt 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 (forretnings-mæssige services, UseCases, processer, begrebsmodel)

At definere en komponent-opdelt applikationsarkitektur Primære aktører:

Applikationsarkitekt, informationsarkitekt Enterprise arkitekt Organisationens applikationsudviklere

C3. Den enkelte service: en kontrakt mellem servicemodtager og serviceudbyder

Forretningsmæssigt niveau: mellem slutbruger og forretnings-service-leverandør:

Tekniske niveau: mellem forretnings-serviceleverandør og teknisk leverandør

Service


Kunde


services

Service


Teknisk Servicearkitektur

SLA forTekniskeservices

B3. Hvad er SOA?Forretningsmæssig synsvinkel

Forretningsrelaterede services – ikke teknologi!


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, …)

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 platforms-

uafhængige Fokus på interoperabilitet (nem

integration – integrationsbus) Brug af åbne standarder for data

og teknologi Specifikation og implementering

af en service er adskilte


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

C3. SOA vision

bruger brugerbrugerbruger

Applikation Applikation

bruger brugerbruger

Ekstern applikation

brugerbruger

Integrationsbus

Fælles portal

B3. Eksempel: Kunde

Kunde

B3/C3. ”Kunde”-servicen som eksempel

Kunde

Opret KundeOpdater kunde automatiskOpdater kunde manuelt...Fo

rretn

ings

serv

ice


Tekn

olog

iser

vice


+KundeID




+AnsøgningsID







Indsender

1

0..*

Beskriver 11

Ejer1

0..*

Har modtaget

1

0..*

Foretages i f t1

1

Kommer fra

11

1

0..*

Har

1

0..*

1

0..*

relaterer til

0..*

0..*

«Sag service»Sag

+Sagsnummer

0..1Refererer til

0..*

1 indgår i 0..1

Har

0..*

1

1

*

1

0..*Harudstedt

Kunde

ServiceAgent


Base


UC 5.42 Opret kunde

UC 5.43 Automatiskopdatering af kunde

UC 5.07 OpretCVR- kunde

UC 5.08 OpretCPR- kunde

Sagsbehandler

Timer

CVR

CPR

GLR

«include»

«include»

«include»

«include»

«include»

«include»

UC 5.47 Genererudtræk af

kundedatabase tilESDH

ESDH

UC 5.15 Behandlanmodning om

oprettelse som kunde

«include»

UseCases

C3. SOA kan gennem SLAs give leverandør-uafhængighed

Kunde

Opret KundeOpdater kunde automatiskOpdater kunde manuelt...



+KundeID




+AnsøgningsID







Indsender

1

0..*

Beskriver 11

Ejer1

0..*

Har modtaget

1

0..*

Foretages i ft1

1

Kommer fra

11

1

0..*

Har

1

0..*

1

0..*

relaterer til

0..*

0..*

«Sag service»Sag

+Sagsnummer

0..1Refererer til

0..*

1 indgår i 0..1

Har

0..*

1

1

*

1

0..*Harudstedt

Kunde

ServiceAgent


Base


Create_userGet_userModify_user

Autorisationskomponenten

OrdningskomponenteParameterkomponente

Hjælperegisterkomponente


services

Ny SLA forTekniskeservices

bruger

C3. ServicearkitekturLeverancetyper

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)

Den røde tråd i OIO EA- baseret på services og Use cases

En ”SOA fra bunden, revolution” tilgang

Sagsbehandler

Ansøgning


Økonomi

Kontrol


Formaliaoverholdt?

Sagsbehandling

ja

Afslag


Start udbetaling

Kontrol

Udbetaling

Modtag udbetaling

Start

Erudbetaling

iorden?

Ja

Afslag


Stop

Nej


Nej

Ja

Nej



Borger

Sagsbehandler

Systemadministrator

CPR/CVR/BBR

Henvendelse

Opretborgerkonto

Opret sag


Sagsbehandling

Udbetaling

Kontrol

Økonomisystem

Vis sagsforløb

Borgerportal


B5. Use cases



Borger Borgerportal


Borger

2. Borger tilgår detaljerede oplysninger om de enkelte sager




B5. Use cases-detaljeret -beskrivelse

















UgyldigDato





C3. ServicearkitekturC3.1 Serviceoversigt (serviceoperation)

Teknisk service <Service-navn> Beskrivelse 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

C3.1 ServiceoversigtTeknisk service Hent_Borgerstamdata 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.



UgyldigDato Teknisk SLA 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.




Reference til B1. Forretningsobjekter

Reference til B5. UseCases

Reference til B3. Forretningsservices

C3. ServicearkitekturC3.3 (Web)service-forretningsservice map

Forretnings-servicebeskrivelse

C3. ServicearkitekturC3.3 (Web)service-forretningsservice map

Mapning af serviceoperationer til Forretnings-servicebeskrivelsen

C4. TeknologiarkitekturOversigt 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

C4. TeknologiarkitekturLeverancetyper

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

C4. TeknologiarkitekturTilgang (TOGAF-inspireret)

Fra generelle teknologivalg til organisations EA

• C4.1 Teknologi referencemodel

• C4.2 ABB (ArkitekturByggeBlokke)

• C4.3 System topologier• C4.4 Udvidede system

topologier

C4. TeknologiarkitekturC4.1 Teknologi referencemodel (eksempel)

C4. TeknologiarkitekturC4.2 Arkitektur byggeblokke Sammenstykninger af hardware og software komponenter der udgør en standard ”logisk enhed”

Afdelingsserver

W e b S e r v e r

T o w e r b o x

F i l e a n d P r i n t S e r v i c e s

F T PF T PF T P

Basis hardware - software

Agenda

Agenda

Agenda

Gap analyse

D1.Restriktioner

D2.Muligheder

D3. Gap analyse

OIO EA metode – Gap analyse

Der identificeres restriktioner af teknisk og forretningsmæssig art. Der kan laves en risikoanalyse – hvoralvorligt er risici, og hvad kan der gøres forat minimere indflydelsen?

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) arkitekturog den ønskede fremtidige (TO-BE). Sammen med trin D1 og D2 skabes dermed etfundament for migreringsplanen.

Gap analyse – D1. RestriktionerD1.1 Restriktioner, konsekvenser og alternativer

Restriktioner beskrives Forretningsmæssige

”Område X kræver a fortsætte med applikation Y af hensyn til lovgivning”

Økonomiske ”Vi kan ikke få råd til X

før 2009” Politiske

”Afd. Z vil ikke acceptere teknologi W”

Tekniske ”Teknologi X

understøtter ikke Y” ”Vi har ikke kompetence

indenfor W”

Konsekvenser beskrives for hver restriktion

”Skal vi både have gammel applikation Y og ny Z, kræver det dobbeltindtastning”

Alternativer beskrives Er der workarounds der

kan afhjælpe restriktionen?

”En integration af Y og Z vil kunne foretages for XX.XXX kroner”

”Vi hyrer expertise indenfor W”

Gap analyse – D1. RestriktionerD1.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 10-30 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!

Gap analyse – D2. MulighederD2.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

Gap analyseD3. 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

Gap analyseD3. Gap analyse

Gruppér trinene i beslægtede indsatsområder (Se trin næste side)

TO-BEAS-IS

Infrastruktur

Integrations-platform

Borgerportal


Gap analyseD3. Gap analyse

Infrastruktur Sikr at infrastrukturen

kan håndtere TO-BE Integrér applikationer til

integrationsplatform Integrér integrations-

platform til borgerportal Integrér integrations-

platform til ledelses-informationssystem

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 ledelses-

informationssystem Uddan i ledelsesinformations-

system

Forandring

E1.Migrerings-

strategi

E2.Migrerings-

plan

E3.Konsekvens -

analyse

OIO EA metode – Forandring

Der udarbejdes en overordnet tilgang tilmigreringen. Forretningen, systemejere og driftsansvarlige inddrages. Temaer: ”big-bang” versus gradvise ændringer, hvordan besluttes migrerings-projekter?, osv.

Der udarbejdes en højniveau-projektplanfor de kommende migreringsprojekter.De enkelte specificeres i nogen detalje,med estimater på tidsplan, aktiviteter,ressourceforbrug, osv.

Konsekvenserne af foreslåedemigreringsprojekter analyseres,mht. årsag til konsekvenser, og mht. hvilken indsats der evt. skal gøres.

E. ForandringE1.1 MigreringsstrategiOverordnet 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 forandringsledelseTæt knyttet til EA governance

E. ForandringE2. Migreringsplan Gennemgå de indsats-

områ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 gantt-chart, under hensyn til afhængigheder og at få mest værdi hurtigt

E. ForandringE2.1 Migreringsplan

2009 2011

AS-IS TO-BE

2008 2010

E. ForandringE3.1 KonsekvensanalyseBeskriv 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”

Agenda


A1.EA-


A2.EA

governance strategi

A4.Projekt charter

A3.EA metode-

grundlag

A5.Vision, mål

og strategier

A6.It-principper

Det sikres at der foreligger en governance strategiallerede inden projektstart, og at der er topledelsesopbakning til at sikre implementering af EA-arbejdets anbefalinger(ellers bliver det næppe en succes).

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

A2. EA governance strategiArbejdsmodel – elementer i organisation

Projekter

Arbejdsgrupper Arbejdsgrupper

Enterprise arkitekt Dokumentations-steward

Arkitektur board

Styregruppe

A2. EA governance strategiEnterprise arkitekt

En enterprise arkitekt er ”metode-fyren” Har autoritet og gennemslags-

kraft i organisationen Er bred (ikke dyb)

Teknisk Forretningsmæssigt Organisatorisk

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



Arkitektur board

Styregruppe

A2. EA governance strategiEnterprise arkitekt – fortsat

En enterprise arkitekt kan være én person eller en gruppe

Nok mest effektivt medén person, der dækkerevt. manglende kompetencer ind via hjælp fra andre

OIO EA rummer forslagtil kompetencer for enenterprise arkitekt

A2. EA governance strategiDokumentationssteward

En dokumentationssteward er ansvarlig for at sikre at der udvikles

og vedligeholdes en EA-dokumen-tationsramme

Valg af modeller (UML, BPMN,…) Valg af rapportformer Valg af værktøjer

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)



Arkitektur board

Styregruppe

EA governanceBarrierer

OrganisatoriskeKulturelle

Finansielle / ressourcer

Kompetencemæssige

PersonerTeknologiske

Vær ærlig omkring barrierer – søg måder at omgå dem



Y3.EA

governance


styring

Y1.Drifts-

situation

Y4.Lovmæssige

bindinger

OIO EA metode – Principper og styring

Essentielt for at etablere og eksekvere de governance strukturer der sikrer at enterprise arkitekturen realiseres. Trinet tager sit afsæt i de rammer der er udstedt i trin A2, ”EA governance strategi”.Det kræver en kontinuerlig ledelsesmæssiginvolvering, for at lykkes.

Y3. EA governanceEA governance processer

Projekter



Arkitektur board

Styregruppe

Forretningsmæssige ogTekniske trends

EA projekt/Portefølje

Assessmentog review

Projekt post-mortem review/

feedback

EA kommunikeret

EA beslutninger(incl. ændringsønsker)

kommunikeret

Overvågning, ændringsønsker

Enterprise arkitekt

Ændringsønsker

Interne og eksterne

Diskussion

EA governance hos jer?

Opsummering

EA metodetrin, og den røde tråd

Sagsbehandler

Ansøgning


Økonomi

Kontrol


Formaliaoverholdt?

Sagsbehandling

ja

Afslag


Start udbetaling

Kontrol

Udbetaling

Modtag udbetaling

Start

Erudbetaling

iorden?

Ja

Afslag


Stop

Nej


Nej

Ja

Nej



Borger

Sagsbehandler

Systemadministrator

CPR/CVR/BBR

Henvendelse

Opretborgerkonto

Opret sag


Sagsbehandling

Udbetaling

Kontrol

Økonomisystem

Vis sagsforløb

Borgerportal


B5. UseCases



Borger Borgerportal


Borger

2. Borger tilgår detaljerede oplysninger om de enkelte sager


Sag.Hent [Journalnummer] (Henter oplysninger om sagen) 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)



















UgyldigDato





Hvordan kommer man igang?

Etablér en arkitektur-gruppe

Ildsjæle Både forretning og it Repræsenteret bredt

Lav intern uddannelse (OIO) EA generelt

A1. EA-relaterede udfordringer - workshop

Formuler EA business case Tag udgangspunkt i A1. Link op til konkrete projekter

(projektportefølje) A4. Projekt charter

Tag udgangspunkt i konkrete projekter

Omfatter EA business case Omfatter A.3 EA metode-

grundlag Veldefinerede (OIO EA) roller I ”ikke-EA sprog”

Præsenter – sælg – GO!

Eksempel# Kategori Rub. Beskrivelse Interessent Konsekvens Vægt

1 Problem F-G Manglende styring.Manglende fælles overblik og styring, ITU ikke altid inddraget i tide.

Alle Usammenhængende og inkonsistente beslutninger om it-projekter. En bedre koordination kunne spare 10% af it-udgifterne om 3 år.

6

2 Mulighed F-IA Borgervendt serviceansigtIntegreret udstilling af alle de informationer samlet har om borgeren

BorgereSagsbehandlere

Borger får større indsigt i sin situation, og adgang til denne 24x7.Kommunen sparer noget ekspeditionstid.

5

3 Mulighed T-AT Mobil arbejdsplads.Udstyre mobile medarbejdere med håndholdte enheder, med mobil adgang til fagapplikationer.

Mobile medarbejdere (hjemmehjælp, vej,…)Borgere

Bedre serviceBedre datakvalitetSparede dobbeltindtastninger

4

4 Problem F-G Svag topledelsesforankring.Svag forankring af arkitekturarbejde i topledelsen.

Alle Arkitekturbeslutninger realiseres ikke, med inkonsistens og dobbeltarbejde til følge.

6

5 Problem F-G Intet fælles sprogMangler fælles sprog for arkitekturtermer.

Alle Et fælles sprog vil fjerne usikkerhed i kommunikationen mellem de involverede, og sikre at arkitekturarbejdes formidles konsistent.

3

Agenda

Kontakt og dialog

Forslag til forbedringer, eksempler, links o.l. Kontakt [email protected] / 5123 4254

Kursus / introduktion til OIO arkitekturværktøjer Kontakt [email protected] / 5123 4254

Dokumenter til registrering i arkitekturbiblioteket Kontakt [email protected] / 3337 9210

Nyheder Abonner på OIO nyhedsbrev

http://www.oio.dk/tilmeldnyhedsbrev

ea.oio.dk

Documents

OIO Enterprise Arkitektur - digitaliser · Michael Bang Kjeldgaard Lars Wilkens Henriksen Jens Peter Koch / Emil Broholm Aalborg 29. oktober 2007 Århus 30. oktober 2007 København