OS2MO 2.0 Fugl Fønix

Transkript

1 OS2MO 2.0 Fugl Fønix OS2MO 2.0 er genoplivet og rulles ud i 18 & men inden produktet rulles ud, gøres brugergrænseflade og kommunikationslag klar (se illustration nedenfor). For at kunne levere et produktionsklart produkt, har det for det første været nødvendigt at udskifte den underliggende database (fra APOS til LoRa) samt det lag ( RESTful interface - eller kommunikationslaget), der sørger for kommunikationen mellem brugergrænsefladen og databasen. Dette projekt er i fuld gang og er finansieret af Aarhus Kommune, Ballerup Kommune og Magenta. Projektet afsluttes pr. 31. marts. Parallelt hermed udføres det projekt, som 31 kommuner finansierer, og som har fokus på at opgradere brugergrænsefladen. Overordnet består dette projekt - 'Opgradering af brugergrænsefladen' - af følgende aktiviteter:

2

3 Projektet afsluttes med at OS2MO 2.0 bliver pilottestet fra og med juni, hvorefter det kan implementeres i andre kommuner. Det er i denne sammenhæng vigtigt at forstå, at projektet går ud på at genskabe det oprindelige MO, som det så ud, da produktet blev opgivet. Det betyder, at der efterfølgende muligvis vil være ønsker til forbedringer, ligesom der måtte have været det til det oprindelige MO. Når projektet er tilendebragt og OS2MO 2.0 er klar til at blive implementeret i kommunerne, vil følgende aktiviteter være nødvendige for hver kommune: 1. Tilvejebringelse af servermiljø, adgange og aftaler 2. Installation af OS2MO 2.0 (på tre servere: UDV-, TEST-, PROD) & LoRa (på tre andre servere: UDV-, TEST-, PROD). Herudover anbefales en server til applikationsovervågning (bemærk, at setuppet kan variere alt efter hvad kommunen ønsker) 3. Opsætning af sikkerhed, dataafgrænsning og autentificering, IdP, ADFS, SAML, mm. (igen - det afhænger af kommunens præferencer) 4. Tilvejebringelse af organisations, medarbejder- og klassifikationsdata 1. Det identificeres, hvilke data LoRa skal populeres med. Det kunne i første omgang gøres ved at identificere, hvilke data STSORG og STSKLA skal bruge. 2. Det identificeres, hvilke afsender-systemer, der indeholder de data, som er identificeret i foregående skridt. De kan både forefindes i lokale systemer (ex AD, SD-Løn) og i fællesoffentlige kilder (ex Serviceplatformen, DAR). Det er dem, OS2MO 2.0 skal integrere til 5. Mapning af afsender-systemets(ernes) data til OIO-standard, sådan at indlæsning af data i LoRa kan ske 6. Indlæsning af data i LoRa - fx ved mox-agenten "Mox Tabel Upload", der giver mulighed for at uploade og downloade LoRa-data som Excel-ark 7. Tilpasning af LoRa/MO til lokale forretningsregler. MO er en generisk brugergrænseflade, som muligvis skal tilpasses lokale behov. Det kan fx være, at der findes et ønske om et nyt indtastningsfelt til BrugerVendt nøgle. Det er ikke et krav til kommunerne, at denne aktivitet gennemføres, blot noget vi skal være opmærksomme på kan forekomme 8. Integrationer. Eksisterende integrationer installeres (fx Mox-agenten til Serviceplatformens CPR-data og integrationen til Dansk Adresse Register (DAR)) og/eller der udvikles nye (ex til SD-Løn, KMD OPUS, AD, m.fl.). Der udvikles ligeledes notifikationer, så LoRa kan abonnere på ændringer i afsender-systemerne. Ændringshåndtering (notifikationer) kan ske enten i realtid (AMQP beskedfordeler) eller ved datadumps (fx XML) - det afhænger helt af afsendersystemernes indretning. Det bemærkes, at heller ikke denne opgave er nødvendig ift. test af selve OS2MO 2.0-applikationen, men det er klart, at det er en prioritet at integrere til andre systemer, så dataflow kan testes. 9. Test og idriftsættelse af hele setuppet

4 Bemærk, at det i forhold til Ad. 8 Integrationer formentlig vil give rigtig god mening, at kommuner med samme systemintegrationsbehov går sammen om finansiering. Således vil fx kommuner med SD Løn kun skulle betale én gang for udviklingen af den Mox-agent, der sørger for at OIO-standardisere data. Det er fordi, ved I, at der er tale om open source. De komponenter, der bliver installeret sammen med OS2MO 2.0, udgør en implementering af rammearkitekturen, og overholder dermed rammearkitekturens principper og giver mulighed for OIOstandardisering af data. De komponenter, som vil blive installeret, er: 1. Brugergrænseflade (OS2MO 2.0). Tillader slutbrugeren at vedligeholde organisations- og medarbejderdata 2. PostGreSQL databasen, der indeholder OIO-services, jf. ID 4 nedenfor 3. RESTful interface, som er kommunikationslaget mellem ID 1 og ID 7 4. OIO-services, som er LoRa-databasens OIO-implementeringer. Klassifikation, Organisation & Log-servicen har direkte relevans, men med installationen af LoRa følger automatisk andre services, nemlig: Tilstand, Indsats & Aktivitet samt Sag & Dokument. 5. Beskedfordeler. AMQP-service, der laver køer, som klientsystemer kan abonnere på. 6. OIO-REST agent, som indeholder den logik, der henter relevante data ud af Beskedfordeleren 7. REST Serviceinterface - API'et til databasen 8. Agent til fejlhåndtering og mailadvisering desangående 9. Mox Upload/Download til popuklering af af LoRa vha. regneark/.csv 10. Mox Advis kan modtage AMQP-besked, hvorpå en til en bruger. Herudover er følgende integrationer enten færdigudviklede eller under udvikling (markeret med *) 1. Dansk Adresse Register (DAR) 2. Serviceplatformen (CPR/CVR) 3. Integration fra AD til LoRa* 4. Autentificering (SAML-ADFS)* 5. Integration til Rollekataloget* Der vil i løbet af projektets forløb - og efterfølgende i det omfang, der er behov for det - blive arrangeret demo-dage, hvor produktet bliver vist, og forskellige emner kan blive diskuteret. Når OS2MO 2.0 er i brug, vil systemet have følgende hovedformål. Disse hovedformål udgør samtidigt produktets business case: 1. Sandhedsdatabase. De data, som OS2MO 2.0 indeholder, er korrekte, autoritative data, uagtet om de indtastes manuelt (manuel indtastning er minimal) i produktet, eller om data fås fra andre kilder. Andre systemer, der har behov for linjeorganisations- og medarbejderdata, kan dermed hente dem fra OS2MO 2.0.

5 2. Synkronisering. De systemer, som er integreret med OS2MO 2.0, bliver ajourførte med korrekte data, herunder STS ORG. 3. Vedligehold. Vedligehold af data vil ske fra én central applikation, der indeholder korrekte data, men vedligeholdet kan ske såvel fra decentralt som fra centralt hold i organisationen. Det vil sige, at forskellige dele af organisationen kan vedligeholdes enten af én person eller af flere forskellige personer. Vedligehold af visse personlige oplysninger kan på sigt crowdsources til den enkelte medarbejder som vha. enapp fx opdaterer eget telefonnummer. 4. Datakvalitet. Data er bundet af de udfaldsrum, klassifikationstjenesten definerer, samt af de autoritative kilder, grunddata bliver hentet fra (fx Serviceplatformens persondata). Dette bevirker at datakvalitet er høj og, som en afledt effekt, at man bliver opmærksom på dårlige datavalitet i de systemer, OS2MO 2.0 henter oplysninger fra, og dermed kan foranledige datarens i dem. 5. Reduktion af arbejdsgange. Data kan oprettes og holdes ved lige fra én applikation. Det betyder, at man ikke længere skal opdatere de samme oplysninger i flere systemer, men kan nøjes med at indtaste dem én gang i OS2MO Automatisering. Mange data vil komme fra andre autoritative systemer, fx Dansk Adresse Register og Serviceplatformen, således at OS2MO 2.0 blot er en autoritativ genspejling af disse data. Det betyder, at de fleste data ikke skal oprettes manuelt, hvilket reducerer antallet af fejl ikke blot i OS2MO 2.0, men i alle de systemer, der modtager data fra OS2MO Datasikkerhed. Datasikkerheden vil blive skærpet i forbindelse med håndtering af medarbejder- og organisationsdata, fordi sporbarhed og sletning kan foretages. Det er således muligt at slette personfølsomme data, spore hændelser samt udtrække informationer om, hvem der har adgang til hvad på et givent tidspunkt (compliance). Jo flere systemer, OS2MO 2.0 leverer data til, jo flere systemer vil være indbefattet af disse muligheder. Datasikkerheden vil følgelig stige i takt med antallet af systemer, som integrerer med OS2MO Ledelsesinformation. OS2MO 2.0 s datagrundlag kan bruges til at udtrække ledelsesinformation af forskellig art. I dag kan dette gøres ved agenten Mox Rapport, men bedre og flere funktionaliteter kan udvikles.