Side 1 av 10 RFI DMSA DWH Markedsundersøkelse - Plattform og infrastruktur for et modernisert datavarehus
Side 2 av 10 RFI DMSA DWH Innholdsfortegnelse Markedsundersøkelse... 1 - Plattform og infrastruktur for et modernisert datavarehus... 1 1 Innledning... 3 2 Om Skatteetaten... 3 2.1 Skattedirektoratet... 3 2.2 Skatteetatens IKT-virksomhet... 4 3 Formål og bakgrunn... 4 3.1 Samtidige aktiviteter overfor markedet... 5 4 Rammebetingelser... 5 4.1 Besvarelsens format og innhold... 5 4.2 Uforpliktende markedsundersøkelse... 6 4.3 Kostnader... 6 5 Tema... 6 5.1 Områder og spørsmål... 6 5.1.1 Teknisk oversikt... 6 5.1.2 Scenarier... 7 5.1.3 Testing muligheter og betingelser... 8 5.1.4 Alternative leveransemodi / produkter og tjenester... 9 5.1.5 Andre kommentarer... 9 6 Tentativ tidsplan... 9
Side 3 av 10 1 Innledning Skatteetatens (SKE) datavarehus trenger modernisering. Ut fra dette behovet ønsker vi å spørre markedet noen nøkkelspørsmål omkring leveranser av en komplett datavarehusplattform. Gartner definerer denne gruppen løsninger som "Data Warehouse and Data Management Solutions for Analytics (DMSA)". Moderniseringen vil forsterke SKEs evne til å prosessere strukturerte data. Videre kan den tjene som en forberedelse for fremtidige evner til å utføre analyser også mot multi- og ustrukturerte data. Hovedmålgruppen for denne markedsundersøkelsen (Request for information (RFI)) er produsenter av egne DMSA-løsninger, som kan levere én helhetlig løsning med maskin- og programvare ferdig integrert. Forespørselen vil også kunne besvares av leverandører som ikke har egne produkter. Kapitlene 3 og 5 anbefales lest dersom man ønsker å vurdere denne RFIens relevans for egen virksomhet. Tredjeparter kan involveres i utformingen av svar til denne RFIen. Leverandører oppfordres til å gjøre det hvis nødvendig. 2 Om Skatteetaten Skatteetaten består av Skattedirektoratet, skattekontorene og Statens innkrevingssentral. Etatens hovedoppgaver er å: forestå folkeregistrering skrive ut skattekort og beregne skatt kontrollere grunnlaget for selvangivelser og andre oppgaver fra skatte- og avgiftspliktige og fra tredjepart kontrollere og fastsette skatt på formue, inntekt og avgifter til folketrygden fastsette og innkreve merverdiavgift, investeringsavgift samt en rekke særavgifter ha det faglige ansvaret for de kommunale skatteoppkrevernes innkreving av skatt kreve inn ulike statlige krav 2.1 Skattedirektoratet Skattedirektoratet er underlagt Finansdepartementet og ledes av skattedirektøren. Skattedirektoratet består av: Det strategiske direktoratet, som har den sentrale faglige og administrative ledelsen av Skatteetaten Skatteetatens IT- og servicepartner (SITS), som er Skatteetatens leverandør innenfor IT og administrative tjenester
Side 4 av 10 Figur 1: Skatteetaten 2.2 Skatteetatens IKT-virksomhet IT-stabens rolle IT-staben i Skattedirektoratet har ansvar for etatens overordnede IT-strategi og samarbeider nært med SITS og de øvrige avdelinger i direktoratet. IT-staben fungerer som rådgiver for skattedirektøren i strategiske IT-spørsmål og har tjenesteeierrollen for IT-infrastruktur. Skatteetatens IT- og Servicepartner (SITS) SITS er Skatteetatens leverandør innenfor IT- og servicetjenester og har ansvaret for å iverksette etatens IT-strategi. Det er valgt en bestiller- leverandørmodell for å styrke fokuset på tjenester. SKD er kunden som bestiller, mens SITS skal levere i henhold til tjenesteavtaler og bestillinger. Tjenesteavtalene skal sikre gode leveranser til etaten og skatteyterne. Bestillinger håndteres av porteføljestyret, som sørger for en helhetlig prioritering av nye utviklingsprosjekter. SITS ledes av en egen direktør, som inngår i Skattedirektoratets ledergruppe og i etatsledelsen. SITS består av 5 avdelinger som leverer IT- og servicetjenestene (Administrative tjenester, Brukersenter, Planlegging, Tjenester og Utvikling). I tillegg har SITS stabsfunksjonene Styring, Sikkerhet og Kvalitet. 3 Formål og bakgrunn Det pågår en omfattende modernisering av Skatteetatens IT-systemer. Nye løsninger må på plass for å møte dagens behov, samt for å tilrettelegge for utvikling av morgendagens tjenester. Som en del av pågående og forestående tiltak for å tilrettelegge for denne moderniseringen vurderer Skatteetaten å erstatte dagens datavarehusplattform med tilhørende infrastruktur. Gitt økende datavolum og stadig mer sofistikert bruk av tilgjengelige data vurderes nye modeller for å møte nye krav.
Side 5 av 10 Vi ønsker at leverandørene presenterer en helhetlig løsning som inkluderer maskin- og programvare. Gitt ulike trender i markedet kan leverandørene også tilføye opplysninger om dataplattformer som er naturlig å utvide foreslått løsning med. Formålet med denne markedsundersøkelsen er å gi Skatteetaten en bedre oversikt over markedet for datavarehus- og DMSA-plattformer. 3.1 Samtidige aktiviteter overfor markedet Skatteetaten gjennomfører også en markedsundersøkelse som har et mer forretningsorientert utgangspunkt, "RFI Advanced analytics and scoring". "RFI Advanced analytics and scoring" har fokus på områdene avansert analyse, visualisering, samt bearbeiding og utnyttelse av nye datatyper. I tillegg vektlegger den muligheter innenfor scoring av aktører og hendelser gjennom bruk av bl.a. prediktive modeller og ekspertregler. Hovedformålet er å kartlegge det løsningsmessige mulighetsrommet og markedets/aktørenes modenhet til å dekke behovene for å: 1. Effektivisere og forbedre arbeidssituasjonen for analytikere, eksempelvis gjennom - bedre verktøy, - mer effektiv modellbygging, - bedre utnyttelse av datakilder, - mer sanntidstilgang på data. 2. Tilrettelegge for utstrakt operativ bruk av analyse og analysemodeller inn i etatens kjerneprosesser gjennom f.eks. risikovurdering ved bruk av scoring og regler. 3. Kontinuerlig overvåking av hendelser kombinert med automatisert mønstergjenkjenning for å avdekke og varsle hendelser og mønstre som indikerer unndragelser og svindelforsøk. Det kan være overlappende problemstillinger mellom disse to markedsundersøkelsene. På områdene datalagring og prosessering kan eksempelvis forretningsmessige behov påvirke tekniske krav og dermed hvilke løsningsvalg som anbefales. Dersom man besvarer begge markedsundersøkelsene ønsker vi at hver besvarelse kan leses selvstendig, uten referanser på tvers av besvarelsene. Det kan eksempelvis løses ved at samme svar gjengis begge steder. 4 Rammebetingelser 4.1 Besvarelsens format og innhold Skatteetaten ønsker besvarelse fra leverandørene skriftlig. Leverandører kan selv velge hvilket eller hvilke standard, elektronisk(e) format(er) som egner seg best for deres besvarelse. Svar Alle temaer vi ønsker svar på er nummerert med bakgrunnsfarge i dette dokumentets venstre marg. Vi ber om at denne nummeringen benyttes i besvarelsen. For de spørsmålene hvor svaret har en kostnadskomponent kan kostnadskomponentene samles, f.eks. i eget dokument, flik i regneark eller tilsvarende. Dette angår spørsmålene 5, 7, 8, 9, 10, 11, 14, 16, 17, 21, 22. Disse spørsmålene er spesielt markert ved at margnummerering er understreket. Vedlagt er et regneark som eksempel på denne strukturen.
Side 6 av 10 1 Skatteetaten ønsker at tilbakemeldingene inneholder: - Leverandørnavn og overordnet leverandørinformasjon. - Leverandørenes kontaktperson(er), herunder navn, e-postadresse(r) og telefonnummer/- numre. - Eventuelt andre relevante leverandørdetaljer. Vi ønsker også svar på så mange som mulig av spørsmålene i kapittel 5.1. 4.2 Uforpliktende markedsundersøkelse Vi gjør oppmerksom på at svar på denne markedsundersøkelsen er uforpliktende både for Skatteetaten og for leverandører som velger å svare. Se kapittel 6 for informasjon om videre prosess. Det gjøres også oppmerksom på at all informasjon oppgitt i dette dokumentet kan bli endret i fremtidige RFIer og/eller anskaffelser. 4.3 Kostnader Leverandøren må selv dekke alle kostnader i forbindelse med deltakelse. 5 Tema I utgangspunktet har denne markedsundersøkelsen et smalt fokus. Likevel oppfordres deltagende leverandører til å beskrive evt. alternative løsninger hvor forutsetninger og antagelser i dette dokumentet ikke stemmer overens med leverandørens produkt- og løsningsportefølje. 5.1 Områder og spørsmål 5.1.1 Teknisk oversikt 5.1.1.1 Dagens situasjon Dagens datavarehus kjøres på to Oracle SMP-instanser uten RAC, men med Partition option. Det inneholder om lag 20 TB data. De største tabellene inneholder opp til ca. 25 mrd. rader, og < 2 TB data. Data er lagret i: - ett skjema for et integrert datavarehus, i noen grad historisert (10 år) - ett skjema tidligere brukt av verktøyet Oracle Discoverer, pr. i dag benyttet som grunnlag for logisk stjernemodellering i Oracle BI (OBI), så vel som for analyse med SQL - ett skjema for ROLAP-stjerner, hovedsakelig for OBI - ulike skjemaer for staging i, subjektscoring m.v. Pr. i dag lastes og transformeres data med ELT-verktøyet Oracle Warehouse Builder (OWB), og xml-transformasjoner utføres i Oracle Data Integrator (ODI). Dette gjøres med om lag 1 500
Side 7 av 10 mappinger, hvorav de aller fleste blir til én SQL-setning som fyller én tabell. Noen script for ulike typer tilrettelegging er implementert i script-språk tilgjengelige på vertssystemet (AIX). Brukerkategorier - De fleste brukere flere enn 2 500 bruker OBI for å benytte seg av datavarehuset. Typisk bruk er f.eks. å kjøre analyser i "Answers"-modulen, eller ulike dashboards. - En annen kategori brukere er analytikere og avanserte analytikere. Disse bruker typisk SQL i Oracle SQL Developer for å tilrettelegge ulike datasett for videre analyse i spesialverktøy. - Videre brukes datavarehuset (av applikasjonsbrukere) til datagrunnlag for automatisert scoring. Datavarehusets data kommer fra ca. 30-40 ulike kildesystemer. Alle interne kilder vil bli modernisert og/eller sanert i løpet av den neste tiårsperioden. Vi antar at analytisk bruk av SQL for å spørre datavarehuset vil øke over den neste femårsperioden, men antar samtidig at andre teknikker gradvis vil supplere dagens bruk av SQL. OBI vil forbli et viktig BI-verktøy for sluttbrukere. 2 3 4 5 6 5.1.1.2 Leverandørs forslag til løsninger Vi ønsker å vite mer om lineært skalerbare DBMS-løsninger hvor maskin- og programvare fortrinnsvis kommer som én leveranse. Hadoop eller liknende tillegg kan presenteres som en del av en slik løsning, eksempelvis for parallell lagring, tolking, og filtrering av rådata. Det antas at de innbyrdes egenskapene og kostnadene til et DMSA på lang sikt vil endres. Vi er derfor også interessert i modeller for plattformfleksibilitet. Slik fleksibilitet kan f.eks. gjennomføres ved å utvide systemets mer kostnadseffektive komponenter på bekostning av mindre kostnadseffektive komponenter, samt flytting av arbeidsmengder ut fra endret konfigurasjon. Hver leverandør oppfordres til å oppsummere: - Hvilke produkter som kan passe med ovennevnte forutsetninger. - Referansearkitektur for hvordan produktene best kombineres til én løsning. - Dersom leverandørens viktigste løsningsmodell(er) ikke passer med forutsetningene beskrevet ovenfor, ønsker vi gjerne en beskrivelse av under hvilke omstendigheter leverandørens løsning likevel kan bli å foretrekke. Dersom leverandører eller deres sertifiserte partnere har systemer/ moduler de antar gir tilleggsverdi til en slik datavarehusløsning oppfordres hver leverandør til å beskrive nevnte systemer/ moduler. Et utkast til fordeler og kostnader relevant til scenarier 1-3 nevnt nedenfor kan også oppgis. Idet vi antar at hver leverandør har vært eksponert for mange ulike prosjekter innen information management (IM ii ) og dataarkitektur, hører vi gjerne tanker rundt generelle kriterier omkring egnethet for langtidspartnere på teknologi på datavarehusløsninger. 5.1.2 Scenarier 5.1.2.1 Data Vi ønsker gjerne en oppsummering av kostnader for nevnt plattform inkludert for tilleggsmoduler (nødvendige eller valgfrie), support, vedlikehold m.v. for følgende scenarier.
Side 8 av 10 7 8 9 Scenario 1: Data er pr. i dag 20 TB / 10 år. Det kan antas at dette øker til ca. 30 TB ved senere anskaffelsestidspunkt. Gitt samme kompleksitet i data ønsker vi også gjerne en kort oppsummering av kostnader for volumer: Scenario 2: 100 TB, Scenario 3: 500 TB. 10 5.1.2.2 Migrering Dersom leverandør har relevant erfaring med migrering av denne typen løsning fra vår plattform til sin(e) plattform(er), ønsker vi kortfattede råd rundt egnede migreringsstrategier. Dette bør inkludere erfaringer rundt tilknyttede kostnader. Relevante detaljer kan f.eks. være datamigrering og strategier for sameksistens. Der hvor dataintegrasjonsverktøy har spilt en nøkkelrolle kan dette gjerne anføres, men kostnader for et slikt verktøy bør ikke inngå i kostnadsoversikt. 11 12 5.1.2.3 Opplæring Hvor mye opplæring bør en gruppe på 20 OWB ELT-utviklere og 5 driftsressurser tilbys for å sikre effektiv drift av og utvikling på systemet. Til hvilke kostnader? Hvor mange DBAer og vedlikeholdsressurser vil ovennevnte scenarier typisk kreve. 5.1.3 Testing muligheter og betingelser I en eventuell anskaffelsesprosess kan testing av løsninger være ønskelig. Slik testing kan eksempelvis ønskes utført på komplette datasett, full kompleksitet og våre prosesserings- /arbeidsmengder. For å være sikre på at vi kan gjennomføre testingen på en god måte, ønsker vi å vite mer om muligheter for å teste leverandørens foreslåtte løsning på en lokasjon i Oslo, estimert i 2-3 måneder. Testene vil i så fall være basert på produksjonsdata som det ikke er tillatt å fjerne fra lokasjonen. Arbeidsmengder vil da være basert på mange samtidige, simulerte spørringer, så vel som på ulike analytiske spørringer mot historiserte tabeller med et antall milliarder rader. Testen kan også bli brukt til å se når og hvordan ytelsen reduseres/forverres. 13 14 15 16 17 Er dette en mulighet dere typisk kan tilby? Hvilke typer kostnader og hva slags kostnader vil dette typisk medføre? Hvilke andre/generelle betingelser vil dere ha? Hva slags rutiner har dere pr. i dag for å sikre data under slik testing? Hvilke kostnader kan være involvert? Eksempler på muligheter som kan vurderes er kjøp av lagringsmedier, dataskrubbing eller ulike kryptografiske opplegg. Hvilke tjenester kan dere tilby for å sikre rask konvertering av skjema og Oracle/ANSI SQLspørringer for å sikre optimal eksekvering på deres DMSA? Hva slags kostnader medfører dette?
Side 9 av 10 18 19 Hvis testing ikke kan utføres som skissert, hvilke andre muligheter foreslås for å sikre at vi har verifisert plattformens evner til å håndtere ulike typer arbeidsmengder? Kan plattformen også leveres på et format egnet for en konvergert, virtualisert infrastruktur på VMware og Intel? 20 21 22 5.1.4 Alternative leveransemodi / produkter og tjenester Vi ønsker en kortfattet liste over måter plattformen kan leveres på utenom som helhetlig maskinog programvareløsning, f.eks. - VMer (på utvikler-pcer, server eller annet) - skytilbud, og gjerne også foreslåtte bruksmønstre, f.eks. - utvikling, - kvalitetssikring. Vi ønsker en kortfattet liste over ulike typer support som kan tilbys, gjerne med anslåtte kostnader. Vi ønsker en kortfattet liste over ulike typer vedlikehold og oppgraderingsmuligheter som kan tilbys (maskin- og programvare). I tillegg ønsker vi et kostnadsanslag for et typisk system som i Scenario 1. 23 24 25 26 5.1.5 Andre kommentarer Er det spesifikke ETL-/ELT-/dataintegrasjonsverktøy og/eller modelleringsteknikker som fungerer spesielt godt med deres løsning? Reduserer eller eliminerer løsningen deres behov for et ETL-verktøy? Kapittel 5.1.3 har en eksplisitt begrensning om at produksjonsdata ikke kan forlate vår testlokasjon. Ulike endringer av f.eks. lov eller forskrift kan føre til at dette endres. Dersom begrensningen endres på følgende måter, hvordan påvirker dette testmuligheter, leveransemodi m.v.? a) data må forbli innenfor Norge b) data må forbli innenfor EØS c) data kan lagres uten geografiske begrensninger I alle de nevnte tilfellene vil SKE kreve komplett og eksklusiv kontroll over data til enhver tid. Beskriv hvordan et slikt krav kan oppfylles, samt effekten av de ulike scenariene for temaene i kapitlene 5.1.1.2 og 5.1.3. Vennligst gjenbruk nummereringen til de spørsmålene som velges besvart som underordnet nummerering, f.eks. 25.a.15 generelle betingelser". Leverandører oppfordres også til å kortfattet oppsummere andre råd eller bekymringer de ønsker å dele med SKE. 6 Tentativ tidsplan Nedenfor følger en tentativ tidsplan for gjennomføring av RFIen.
Side 10 av 10 Nr Aktivitet Dato 1 RFI distribuert på Doffin 15.12.15 2 Frist for leverandørene til å stille spørsmål 22.01.16 3 Frist for å melde interesse for møte 08.01.16 4 Møte med leverandører som har bedt om det 11.-22.01.16 5 Innleveringsfrist besvarelse på RFI 31.01.16 6 Eventuelle møter med leverandører 01.02-31.03.16 Etter innleveringsfristens utløp vil vi gå gjennom besvarelsene som er kommet og vurdere å invitere leverandørene enkeltvis på møter for gjennomgang. SITS vil presentere en analyse av svarene opp mot ledelsen, som i sin tur vil vurdere og beslutte det videre løpet. Gitt godkjennelse hos ledelsen kan videre tiltak innebære en anskaffelse eller en ny RFI. Kontaktinformasjon ved spørsmål Eventuelle spørsmål sendes på epost til: RFI_DMSA_DWH@skatteetaten.no Alle spørsmål og svar vil i en anonymisert form bli publisert på Doffin. Forespørsel om møte Leverandører som ønsker det kan be om et møte for avklaringer og dialog rundt RFIen, samt stille spørsmål. Det bes om at det sendes forespørsel om dette så snart som mulig, og senest 8.januar 2016, da møtene vil finne sted i perioden 11.-22. januar 2016. Innsending av besvarelse Besvarelse sendes elektronisk per e-post til RFI_DMSA_DWH@skatteetaten.no, merket med tittelen "leverandørnavn besvarelse RFI DMSA". Vi vil sende en bekreftelse på mottatt besvarelse (per e-post). Leverandør velger selv om besvarelsen gis på norsk eller engelsk. Frist for besvarelse 31. januar 2016. Møter i etterkant av mottatt besvarelse Skatteetaten vil etter at besvarelsene er mottatt og gjennomgått vurdere å invitere leverandørene enkeltvis til møte for videre dialog. Slike møter vil i så fall finne sted i perioden februar-mars 2016. i Staging er en samlebetegnelse på aktiviteter rundt forberedelse til last, transformering m.v. ii Information management (IM), Læren om systematisering av informasjonsbruk for virksomhetsbehov.