310 likes | 477 Views
ÖTP-möte Stockholm 2006-10-26 Presentation (+ vissa mötesanteckningar). Verksamhetsutveckling & sambruk av kommunala e-tjänster. Agenda. 10.00-10.10 Inledning och presentation 10.10 -11.00 Förslag presenteras av Microsoft Douglas Hamilton
E N D
ÖTP-möteStockholm2006-10-26Presentation (+ vissa mötesanteckningar) Verksamhetsutveckling & sambruk av kommunala e-tjänster
Agenda • 10.00-10.10 Inledning och presentation • 10.10 -11.00 Förslag presenteras av Microsoft Douglas Hamilton • 11.00-12.00 Genomgång av Sambruks upphandling Barnomsorgen ( ÖTP) • 12.00-13.00 Lunch • 13.00-14.30 Förslag till upphandling -avrop på Integrationskravspecifikation • ÖTP version 1.3 -2.0 • 14.30-15.00 Kaffe • 15.00-ca 16.30 Avrapportering från MSI-paketerings nätverket • Metakatalognätverket ( strategiskt och operativt perspektiv) • Verksamhetsplan 2007 • Övriga frågor • Nästa möte
Ang. BizTalk & Curalia ( & Oracle?) och generell integration relativt Decapus/TEIS...
Fil Decapus Fil Ev autostart från Decapus av utläsnings-jobb Ev autostart från Decapus av inläsnings-jobb ”Fil-adapters” Många har Decapus idag... • De flesta användningarna av Decapus (och TEIS ännu) är endast ren fil-integration gentemot fil-gränssnitt som verksamhetsapplikationerna i sig ”äger” – dvs inget egentligt adapter-behov i dessa fall – men man kallar ofta [1: kontrollen av filöverföring, 2: autostart av in/utläsning], för adapters. Vi bör göra ett begreppsdefinitionsarbete här... • Ingen volymskostnad, endast årlig licens Verksamhets-applikation A Verksamhets-applikation B Fil- gräns- snitt Fil- gräns- snitt
Decapus med eBizGate • Ibland används dessutom TE:s nav för dataöverföring, konvertering etc. • Kännbar volymskostnad plus årlig licens Verksamhets-applikation A Verksamhets-applikation B eBizGate- Nav $$$ Fil- gräns- snitt Fil- gräns- snitt Decapus Decapus
Fil Decapus Fil Ev autostart från Decapus av utläsnings-jobb Ev autostart från Decapus av inläsnings-jobb ”Fil-adapters” Adaptrar utanför verksamhetsapplikationerna... • Ifall ”adapterkomponenter” skapas utanför verksamhets-applikationerna i sig ska dessa utvecklas och förvaltas (upphandlat av Sambruk t ex) Verksamhets-applikation A Verksamhets-applikation B Fil- gräns- snitt Fil- gräns- snitt
Medd. TEIS mfl Medd. Online-användning... • Ifall det är online-behov istället så funkar inte Decapus utan TEIS, BizTalk, Curalia, Oracle kan ev. komma ifråga (idag dock endast vid ej höga prestandakrav) • Detta online-fall är ÖTP v1.2:s huvudscenario och där duger SOA och Web Services för Nyttomeddelanden, integrationsmotor behövs inte initialt, utan i så fall i ett senare skede för att undvika ”spaghetti” Verksamhets-applikation A Eller snarare e-tjänst... Verksamhets-applikation B Online gräns- snitt Online gräns- snitt ”Nyttomeddelande-adaptrar online”
Decapus/TEIS-moduler • Till Decapus eller TEIS kan varje kommun köpa paketerade integrationer (s k moduler) – de har en prislapp! Prisex TEIS (möjl har man sänkt priset nu…): • Automatstart Devis-X el Procapita IFO el KIR: • 18000 kr • Paket Respons el LPS el Devis-X: • 18500 + installation 8950 • Paket Procapita-KIR: • 5200 + installation 8950 • Ofta tillkommer löpandekonsulting för anpassning...
Back-end-integration Back-end-integration inkl back-end-processtöd – typisk EAI Ev via gamla integrations-vägar eller befintlig SHS Adapteringar? Ev. processtöd SOA-adapter? Nytto-meddelande-implementation Front-endWebb-applikation Existerande verksam- hets-applikation SOA-arkitektur Extern part,myndighet etc (EAI = Enterprise Application Integration)
En prisfråga mot en leverantör Frågan körs mot en lokal kopia av prisregistret (uppdatering av lokalt register kan t ex ske via meddelanden per dag eller vecka) Några exempel från e-handel… som ger olika krav på online eller klassisk EAI eller mittemellan... • En lagersaldofråga mot en leverantör • Frågan körs online mot leverantören • En faktura går till en kund • Fakturan överförs via en kö på någon timme till kunden Verksamhetsbehoven ska styra krav på datafärskhet...
Anskaffandestrategi • 23 kommuner deltar nu i projektet! • Del 1: Avrop för Nyttomeddelande-implementationer (på befintliga applikationsavtal som varje kommun har med sin leverantör av verksamhets-applikation) • Del 2: Komplett upphandling för e-tjänsten
Barnomsorg Mönster enl ÖTP V1.2 kapitel 2.2 X Applikationen har införtSambruks.exakta nytto-medd. via Web Service E-tjänst för föräldrarNy webb-applikation (eller modifierad/förbättrad) Y Applikationen har ett ”högnivå”-API, t ex viaCOM eller RMI SOA Anpassningslogiken (s k adaptrar) måste bli olika omfattande (från ingenting till ”tjock”), beroende på resp. verksamhetsapplikations möjligheter – i Barnsomsorgs fall nu blir det mest variant X Z Applikationen har inget API, tvingas gå direkt via SQLmot databasen = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services). = Proprietära/specifika anrop per verksamhets- applikation/tjänst.
Del 1: Avropsdelen • Avrop på befintliga applikationsavtal för IST, Tersus, TE • Mittvariant Y (fg bild) är vad vi vet inte möjlig eftersom öppenheten är för dålig i de tre verksamhetsapplikationerna idag • Nedre varianten Z är inte lämplig eftersom de tre verksamhets-applikationerna, vad vi vet, inte har publicerade datamodeller (samt saknar uppdateringslogikskydd etc). • Planerad avropsförfrågan gäller alltså övre varianten, X(härvid uppstår alltså inga adaptrar ur Sambruks synvinkel utan endast leverantörens Nyttomeddelande-implementationer) • (Reserv-variant screen-scraping gör att vi inte är helt inlåsta hos leverantörerna utan skulle kunna köpa detta från oberoende part)
Del 2: Upphandlingsdelen • Komplett LOU-upphandling mha Kommentus av e-tjänsten (webbapplikationen) för barnomsorg • Denna ska kommunicera via Sambruks specade Nyttomeddelanden med bakomliggande verksamhetsapplikation • Driftbart sept 2007 ?
Status generell integration • Specifikation v0.9 på remiss sedan senaste möte • Några remissvar inkomna, t ex: • Positiva till struktur och att det blir lätt att använda som upphandlingsbilaga • Några invändningar mot språkbruk • En invändning mot att använda “Beskriv-krav” • Torde gå att göra mindre mängd redigeringar för att möta upp synpunkterna och leverera en v1.0
Status de olika initiativen? • MS BizTalk ? • Curalia ? • Oracle ? • TEIS • Får vi en instegslicens motsvarande Decapus? • Rabattförhandling via Sambruk? • Integrationsanskaffning • Hur går vi nu vidare med anskaffning?
Saxat ur produktbladet för ÖTP v2.0: • “... kan ÖTP ange en teknisk ’roadmap’ internt och för leverantörer” • “...förutom beskrivande text ska där också finnas ett antal konkreta kravformuleringar”, jmf Generell integration • “... tekniska utvecklingen har också fortsatt så en uppdatering av ÖTP av den orsaken behövs tillika” • “Tidplanen är 2006-10-16 – 2007-01-31”
Fokusområden • Allmän modernisering av texten • Uttrycka konkreta kravpunkter • Ytterligare fokusområden enligt produktbladet: • Portal/ytintegrering, bl a SSO • Webbpublicering/Content Management • Metakatalogreplikering • Workflow/processtyrning
Konkreta leveranser och kontinuitet Nuvarande e-tjänster inom Sambruk skapas Samtidigt skapas de ÖTP-delar som behövs just till dessa e-tjänster. Vid detta tillfälle alltså inget större nytt verksamhets-projekt som ställer nya krav på ÖTP, mer en fråga om förvaltning av ÖTP i sig. Nästa e-tjänst ... ÖTP-delar ... ÖTP-delar ... Nästa e-tjänst ... ÖTP-delar ... Första e-tjänst, Biståndsprojektets webb-applikation + adaptrar Samtidigt skapas de ÖTP-delar som behövs just till denna e-tjänst. Inom respektive e-tjänsts budget. Flera lev. är tänkbara parallellt. Nästa e-tjänst ... Uppsyn ÖTP-förvaltning & ÖTP-vision tid Slimmad, lätt men kontinuerlig organisation som bl a förvaltar arkitektur & planer. Missionerar för ÖTP hos kommunerna. Uppsyn över sambruksprojekten. Bevakar teknikutvecklingen. Har leverantörskontakter.
Arbetsformer • Bredare insamling av behov, kunskap och synpunkter bland medlemskommunerna, förankring nu när vi inte har en konkret tillkommande kravbild från verksamhetsutredningar...
Återanvända arbetsform från verksamhets-specandet?Bistånd gjorde så här (övr 5-piloten likadant):
Förslag arbetsformer • Seminarieform med referensgrupp vid två seminarietillfällen • Ett tillfälle Sambruksdygnet 30/11-1/12 • Ett extra datum eller ett vid nästa ÖTP-möte • Ev kompletterande synpunktsinhämtning per e-post • Publicering av v0.9 2007-01-31 för slutremiss • Mötesanteckning: Slutdatumet bör anpassas till andra upphandlingar etc – ev senarelägga
Diverse • Förslag: Testbänk för Nyttomeddelanden för att lättare sprida vår ”standard” och att inte riskera dålig interoperabilitet ? • Förslag: Prototyp för ”hängränne-applikation” som stöd till kontakt-center ? • Lägesrapport Bistånd • Uddevalla går precis i drift med CSN-datahämtning via SHS till tilläggsbild i Procapita • Borlänge tänker prova en minilösning med enkla html-filer eftersom Sofia snart ska pensioneras
Sven-Håkan Olsson Sambruk / Definitivus 0708 – 84 01 34 sven-hakan.olsson@definitivus.se Sambruk_Sthlmmoete_OETP_okt06_v2.ppt Verksamhetsutveckling & sambruk av kommunala e-tjänster