Integration i region Syddanmark (RSD)

• Region Syddanmarks integrationsarkitektur
• Retningslinier for WebService i RSD
• Integrationsspecifikationer (Baseline)
• Processer og ansvar ifm. systemintegration
• Integrationsteam
• Drift og support
• Versionstyring
• Ekstern adgang til Baseline

Region Syddanmarks integrationsarkitektur

Nedenstående dokumenter beskriver regionens integrationsarkitektur og anvisninger for test:

• Integrationsarkitektur i Region Syddanmark (AIP dokument) ver 2.0.0.doc
• Anvisninger for test i Region Syddanmark (standard-udbudsbilag)

Processer og ansvar ifm. systemintegration

Det er nødvendigt, at projekter og forretningen i samarbejde med regionens integrations arkitekt identificere, hvilke integrationsbehov, service og data der er nødvendige i den pågældende integration.

Detaljeringsgraden af integrationen afhænger naturligvis af den pågældende situation da der vil være forskel på om systemet allerede er anskaffet eller systemet via en kravspecifikation skal anskaffes. .

I nedenstående procesdiagram gennemgås, hvilke aktiviteter/processer der skal gennemføres / leveres af henholdsvis forretningsområdet / projektet og integrationsteamet. I processdiagram 1 gennemgås integrationsaktiviteter ved en udbuds- anskaffelsesproces. Når udbuds- eller anskaffelsesprocessen er overstået og der er valgt system og leverandør vil de samme integrationsaktiviteter være gældende som ved eksisterende systemer, se processdiagram 2.

 Processdiagram 1 - procesbeskrivelse ved udbud nyanskaffelse

I procesdiagram 2 gennemgås integrationsaktiviteterne vedr. ændringsønsker af eksisterende systemer eller ved udstilling af nye services. Der indgår to startpunkter i dette diagram, hvor det ene startpunkt handler om et eksisterende og kørende system som er integreret i forhold til regionens infrastuktur, men ønsker ændringer eller udvidelser af de eksisterende integrationer. Det andet startpunkt, handler om et system der netop er anskaffet evt. ved et udbud og endnu ikke er i drift, men der skal ske en afklaring vedr. systemets integrationer.

 Procesdiagram 2 - Processer ifm. integrationsændringer af eksiterende systemer eller ved integration af nyt system

Når der ud fra en teknisk synsvinkel skal foretages integration imellem systemer eller der skal udstilles services fra eksisterende systemer er dette ofte nemmere at udføre, hvis forretningen via workflows og use-cases evt. med hjælp fra projektintegrationsteamet beskriver hvad den pågældende integration skal understøtte. Det er derfor nødvendigt, at der udarbejdes use-cases og eventuel sekvensdiagrammer i forbindelse med hver enkelt integration. Endvidere er det nødvendigt, at der udarbejdes en system- løsningsbeskrivelse enten af projektet, men som regel af leverandøren så projektintegrationsteamet, projektet og leverandøren har en fælles opfattes af integrationsopgaven.

Integrationsplatformen vil ende med at blive kompleks og retningslinierne for integration via platformen vil ligeledes være komplekse og svære at lave fyldestgørende i forhold til de spørgsmål der opstår i konkrete projekter. Kan et system eller et projekt ikke efterleve retningslinierne i AIP skal der udarbejdes en indstilling til integrationsteamet som minimum bør indeholde:

1. Beskrivelse af problemstilling med argumentation for hvorfor gældende principper og retningslinier ikke kan overholdes.

2. Beskrivelse af omfang og indhold af undtagelse. Hvor bredt et område dækker undtagelse og den praktiske betydning af undtagelse

3. Beskrivelse af evt. afledte konsekvenser af undtagelse, specielt hvis undtagelse påvirker andre projekter/teams eller grænseflader

4. Stillingtagen til om undtagelse skal være af temporær eller permanent karakter

Projektintegrationsteamet vedligeholder en log over undtagelser fra principper på tværs af alle projekter

Integrationsteam

Til at organisere arbejdet omkring integrationer i region Syddanmark oprettes der et integrationteam hvor de implicerede parter/leverandører regelmæssigt mødes for at diskutere konkrete integrationsløsninger samt koordinere integrationsarbejdet på tværs. Ved større projekter er det nødvendigt, at integrationorganisation opbygges og der laves en formel proces med regelmæssige møde, hvor det ved mindre integrationer ikke er nødvendigt, at formalisere organisationen. Det er vigtigt, at samtlige roller er repræsenteret, hvor den samme person oftest varetager flere roller.

Integrationsteamet med undtagelse af teamlederen og leverandørens repræsentanter vil ofte være de samme personer fra regionen, hvilket sikrer:

1. dybdegående kendskab til integrationplatformen og dens services.
2. ensartethed på tværs af kontrakter og dokumentationen af dem. Teamet sikrer, at alle kontrakter overholder et sæt af retningslinier (navnekonventioner, versionering, faste headers osv.)
3. overblik over alle kontrakter - herunder at der ikke opstår redundante datadefinitioner (fx på personer) eller overlappende operationer.

Integrationsarkitekt

Internt i regionen har integrationsarkitekten for eksempel et ansvar for sikring af regionens integrationspolitik (AIP), inddragelse i kravspecifikationer osv.. Derudover skal integrationsarkitekten også indgå i større integrationsprojekter hvor integrationarkitekten designer med hjælp fra leverandørens repræsentant det enkelte projekts overordnet integrationsløsning. I tabellen nedenfor fremgår ansvar for opgaver.

Integrationsudvikler

Integrationsudvikleren skal udvikle og implementere integrationsløsningen i henhold til integrationsarkitektens løsningsdesign. Relevant dokumentation kan / skal udarbejdes i samarbejde med leverandørens integrationsudvikler. I region Syddanmark tilfælde kan integrationsudvikleren og integrationsarkitekten være den samme person.

Test manager

Test manageren er ansvarlig for koordination og udarbejdelse af testplaner i forhold til integrationsteamet. Det overordnede ansvar for, at arbejdet omkring testplaner igangsættes, udarbejdes samt koordineres ligger hos teamlederen/projektledelsen. Det er regionens udviklingssektion samt leverandørens integrationsudviklere som deltager i udarbejdelse af testplaner og er der brugeraccepts involveret i testen skal brugerne også involveres i testplanen. Det er IKKE testmanageres opgave i integrationsteamet, at udarbejde funktionelle testcases og gennemføre disse, men testmanagere skal teste "hul igennem", perfomance, data-/beskedindhold samt sørge for at stille testdata til rådighed.

Drifts / support manager

Drifts / support mannageren sætter integrationer i produktion samt overvåger disse integrationer.

Teamleder

Teamlederen er som oftest den tekniske projektleder der allokerer ressourcer og koordinere projektintegrationsteamet sammen med de involverede parter og leverandører. Det er vigtigt, at leverandøren også stiller med en eller flere personer med projektkvalifikationer, hvilket svarer til den tekniske projektleder.