SSA-T Bilag 3 vedlegg 1 Arkitektur og rammeverk IKT/GIS-utvikling Miljødirektoratet Versjon 2016.2 Side 1 av 8
1. Om dokumentet Dokumentet gir en oversikt over arkitektur og rammeverk som skal benyttes ved utvikling av GIS-integrerte applikasjoner i Miljødirektoratet. Dokumentet skal følge som vedlegg til kravspesifikasjon ved innhenting av anbud eller ved direkte innkjøp i forbindelse med utvikling av applikasjoner. Formålet er å gi applikasjoner i Miljødirektoratet mer enhetlig utforming i forhold til funksjonalitet og utseende og forenkle driftsrutiner og videreutvikling. 2. Innledning De tekniske vurderinger som ligger til grunn for dette dokumentet er gjort i henhold til: «Overordnede IKT-arkitekturprinsipper for offentlig sektor» fra Difi (http://www.difi.no/sites/difino/files/arkitekturprinsipper-2.1.pdf) «Rammeverk og infrastruktur for stedfestet informasjon i Norge» fra Norge Digitalt (http://www.statkart.no/geonorge/norge-digitalt/veiledere) Fra Difis Arkitekturprinsipper: Regjeringen har besluttet at IKT løsninger for statlige virksomheter, skal bruke felles arkitekturprinsipper. Dette skal bidra til bedre brukerorientering og mer samordning på tvers av offentlige virksomheter. I forvaltningsmeldingen St.meld. nr. 19 (2008-2009) Ei forvaltning for demokrati og fellesskap presenteres de sju arkitekturprinsippene som skal følges. Tjenesteorientering Interoperabilitet Tilgjengelighet Sikkerhet Åpenhet Fleksibilitet Skalerbarhet Det er obligatorisk for statlige virksomheter å bruke prinsippene ved utvikling av nye ITløsninger eller ved vesentlige endringer av eksisterende løsninger. Dersom det etter en helhetlig vurdering er klare ulemper eller utilsiktede konsekvenser ved å følge enkelte av prinsippene i det konkrete prosjektet, kan de prinsippene det gjelder fravikes. Fraviket må begrunnes. Det legges dermed til grunn et krav om «Bruk eller forklar». Det skal dokumenteres hvordan arkitekturprinsippene er fulgt ved satsingsforslag og ved etablering av store eller strategisk viktige prosjekter med vesentlig innslag av IT. Side 2 av 8
3. GIS arkitektur 3.1 Verktøy og teknologi Verktøy Primær teknologi Sekundær teknologi GIS Server ArcGIS Server Geoserver ETL (extract, transform, load) UML modellering Utviklingsmiljø / platform Kart innsynsløsninger FME (Workbench, Server) Enterprise Architect Visual Studio (.NET / C#) Geocortex Essentials Egenutviklede (ArcGIS JavaScript/.NET) ESRI Model Builder Open Layers Web Server Microsoft IIS Apache / Tomcat Databaseserver Mockup / form design SOSI konvertering MSSQL Server (med SDE når romlige data benyttes) Balsamiq Mockup builder GDM Mapper ESRI File Geodatabase (kun statiske datasett) MSSQL Server (spatial) Inndeling i primær og sekundær plattform er gjort for å synliggjøre hvilken teknologi vi foretrekker å bruke så fremt det er mulig. Fortrinnsvis ønsker vi å holde begrense mengden systemer vi vedlikeholder, men vi utelukker ikke bruk av det vi definerer som sekundær teknologi i unntakstilfeller. Det skal i så fall begrunnes. 3.2 Geodatabaser Alle romlige data som lagres i database skal fortrinnsvis benytte ESRIs SDE database format på MSSQL server. I de tilfeller der det er naturlig å lagre data i filformat for presentasjon via ArcGIS server eller Geoserver skal ESRI Shapefile eller ESRI File Geodatabase benyttes for vektordata. GeoTIFF eller JPEG2000 benyttes for rasterdata. 3.3 Konvertering og eksport / import av romlige data (ETL) Enkelte applikasjoner og databaser har behov for import og eksport av data til og fra brukere. Innlegging og presentasjon av data håndteres normalt ved hjelp av Side 3 av 8
applikasjonen/innsynsløsninger eller standard protokoller (WMS, WFS, ArcGIS REST etc.), men det kan være tilfeller der dette ikke er tilstrekkelig. For eksempel: Store mengder data (f.eks..csv-filer eller.gpx (GPS-tracklog)) som krever kontroll/vask før import til databasen. Data som må topologikontrolleres før import (SOSI og andre geodata-filformat). Eksport av hele eller deler av datasett for behandling i brukerens egne verktøy (f.eks.csv filer for Excel eller SOSI-filer i Fysak) Ved konvertering til/fra SOSI via FME skal plugin-modulen GDM Mapper benyttes. I slike tilfeller benyttes FME server til prosessering (mottak, konvertering, kontroll/vask og eksport) av data. FME server har et godt dokumentert REST API (http://fmepedia.safe.com/articles/samples_and_demos/fme-server-rest-playground) som gjør at man kan benytte FME til backend-prosessering av data fra andre applikasjoner. FME er spesielt godt egnet til behandling av romlige data, men kan i praksis benyttes til de fleste typer data. FME Workbench benyttes for å definere arbeidsflyt og grensesnitt på FME Server. 3.4 Basiskart Som basiskart benyttes fortrinnsvis ArcGIS-baserte basiskart fra Geodata (Geodata Online) og Norsk Polarinstitutt sine ArcGIS-baserte kart for Svalbard. Eventuelt kan Kartverket sine WMTS tjenester for fastlands-norge benyttes. 3.5 Datum og kartprojeksjon Følgende datum og kartprojeksjoner benyttes i Miljødirektoratets applikasjoner ved presentasjon og håndtering av romlige data: Datum Projeksjon EPSG kode WGS84 UTM 29 EPSG:32629 WGS84 UTM 30 EPSG:32630 WGS84 UTM 31 EPSG:32631 WGS84 UTM 32 EPSG:32632 WGS84 UTM 33 EPSG:32633 WGS84 UTM 34 EPSG:32634 WGS84 UTM 35 EPSG:32635 WGS84 UTM 36 EPSG:32636 Side 4 av 8
EUREF89 UTM 29 EPSG:25829 EUREF89 UTM 30 EPSG:25830 EUREF89 UTM 31 EPSG:25831 EUREF89 UTM 32 EPSG:25832 EUREF89 UTM 33 EPSG:25833 EUREF89 UTM 34 EPSG:25834 EUREF89 UTM 35 EPSG:25835 EUREF89 UTM 36 EPSG:25836 WGS84 Geografisk 2d EPSG:4326 WGS84 Mercator EPSG:3857 3.6 Standardisering og Metadata Dersom romlige datasett skal publiseres på Internett skal Metadata være spesifisert i henhold til den norske ISO-profilen 19115 Geografisk informasjon. NS-EN ISO 19115 foreligger delvis som en del av SOSI i en norsk oversettelse som inneholder de normative deler av standarden. Se http://www.statkart.no/sosi/pdf/del1_5_metadataprofil.pdf Datamodell for romlige data skal spesifiseres iht gjeldende SOSI standard (objektkatalog) og INSPIRE-direktivet for å sikre at Miljødirektoratet kan levere data iht de forpliktelser vi har (Geodataloven/forskriften). 4. Utviklingsverktøy og API for utvikling Standard rammeverk for server side applikasjoner er Microsoft.NET. Vi foretrekker kildekode i C#, men Visual Basic kan også brukes hvis det dreier seg om gjenbruk av komponenter. Rammeverk for kommunikasjon med SQL Server er Entity Framework. For klientapplikasjoner som benytter HTML5/JavaScript kan JQuery/JQuery UI, Dojo og Bootstrap benyttes som støttebibliotek. Applikasjonene skal primært utvikles i Microsoft Visual Studio. 4.1 Utviklingsverktøy og klient rammeverk for GIS Primært skal Miljødirektoratet benytte to plattformer for utvikling av applikasjoner med kartfunksjonalitet: Side 5 av 8
Geocortex Essentials fra Latitude Geographics er et rammeverk og server plattform som lar brukeren definere egne kartapplikasjoner ved hjelp av et web-basert grensesnitt og tilpasning av XML-filer. Brukeren velger utseende og kartlag og kombinerer dette med «workflows» for standardoperasjoner som krever spesifikk input fra bruker. Definisjon av webområdet og evt «workflows» lagres i egne konfigurasjonsfiler som deretter kan benyttes av ulike standard klienter. I Miljødirektoratets tilfelle har vi valgt å satse på JavaScript/HTML5 (Silverlight er i bruk, men skal fases ut). Geocortex fortrinn er at applikasjoner kan utvikles med minimal bruk av programmering, men Geocortex har også et.net/visual Studiointegrert SDK som gjør det mulig å lage egne utvidelser når standard funksjonalitet ikke er tilstrekkelig. Oppgradering til nye versjoner av klient og serverprogramvare er forholdsvis enkelt da funksjonalitet og arbeidsflyt er skilt fra klienten. ArcGIS JavaScript API er foretrukket rammeverk for kartintegrerte applikasjoner som krever større grad av tilpasning. ArcGIS JavaScript API benytter Dojo som basisbibliotek. Server side skal Microsoft.NET rammeverk benyttes så langt dette er mulig. Eventuelle tilleggsbibliotek skal spesifiseres i tilbud og godkjennes av Miljødirektoratet. Open Layers skal kun benyttes til enkel visualisering (f.eks. for å visualisere et datasett med elementær kartfunksjonalitet) der det er hensiktsmessig, men i de fleste tilfeller vil ArcGIS JavaScript API kunne benyttes i stedet. Enkelte applikasjoner benytter av ulike årsaker Open Layers allerede, og for disse kan man fortsatt benytte Open Layers. Ved større oppdateringer av systemene skal de foretrukne teknologiene vurderes (Geocortex Essentials eller ArcGIS JavaScript API). 4.2 Web services og direkte tilgang til romlige data Applikasjoner skal bygges slik at relevante ikke-romlige data som har allmenn interesse, eller som med fordel kan benyttes av flere applikasjoner, gjøres tilgjengelig som web services i tillegg til sine respektive applikasjoner og innsynsløsninger. Det dreier seg i første rekke om innsyn i data av ikke-sensitiv art, men i relevante tilfeller kan det vurderes å implementere sikkerhetsmekanismer som muliggjør skrivetilgang og tilgang til sensitive datasett. Web services skal være REST-baserte og i utgangspunktet ta imot forespørsler og levere data formattert som XML og JSON. Rammeverket som benyttes på server skal i utgangspunktet være Microsoft.NET Web API (MVC). Romlige data presenteres for publikum gjennom standard OGC-protokoller (WMS, WFS) int. retningslinjer fra Norge Digitalt. ArcGIS REST API benyttes i egenutviklede applikasjoner så langt det er hensiktsmessig. 4.3 Bruker og rolle styring Miljødirektoratet har planer om å ta i bruk et IAM-system for autentisering og autorisering som fungerer på tvers av flere web applikasjoner. Dette for å unngå at brukere må holde kontroll på flere sett med påloggingsinformasjon. Systemet er ikke ferdig implementert i Side 6 av 8
organisasjonen enda, og vi kan derfor ikke være konkrete på hvordan utvikler skal forholde seg til dette i detalj. Frem til at dette systemet er implementert vil det i de fleste tilfeller være ønskelig å bruke Miljødata sin installasjon av Identity Server 3 til autentisering. Rollestyring av tilgang til databaser/applikasjoner som inngår som en del av Naturbase-paraplyen håndteres via et eget REST API. I andre applikasjoner der man har behov for en enklere rollemodell kan det vurderes å bygge dette direkte inn i applikasjonen. 4.4 Kartforvaltning Med verktøy for kartforvaltning menes verktøy som benyttes til lagring, redigering, presentasjon, analyse, import og eksport av romlige data. Miljødirektoratet har standardisert på ArcGIS Desktop som primært verktøy for brukere med behov for funksjonalitet ut over det som finnes i våre applikasjoner og innsynsløsninger. ArcGIS Desktop brukt mot ArcGIS Server og MSSQL/SDE og ESRI File Geodatabaser danner til sammen Miljødirektoratets hovedplattform for kartforvaltning. 4.5 Sikkerhet Vi følger Microsoft sin standard sikkerhet for implementering av løsninger. Se følgende lenker https://msdn.microsoft.com/en-us/library/330a99hc%28v=vs.100%29.aspx https://msdn.microsoft.com/en-us/library/zdh19h94%28v=vs.100%29.aspx Hvis løsningen inneholder sensitive data som krever økt sikkerhet, vil dette være eksplisitt beskrevet. 4.6 Testdreven utvikling Ved utvikling av løsning skal det bygges inn automatiske tester (unit-tester og integrasjonstester). Det er viktig at dette gjøres på de kritiske elementene, slik at feil ved fremtidige endringer reduseres. 4.7 Kildekode For kildekode håndtering skal Miljødirektoratets GitHub område benyttes. 4.8 Bygg og deploy server Versjoner av løsningen skal lages via byggserver, som er tilknyttet Miljødirektoratets kildekode løsning (se punkt over). Verktøy for bygging er TeamCity (JetBrains). Dersom noen Side 7 av 8
av de automatiske testene gir feil, skal ikke versjonen bygges. Byggserver er å betrakte som infrastruktur og skal konfigureres/settes opp i starten av et prosjekt. For utplassering/deploy benyttes Octopus. 4.9 Versjonshåndtering Det er viktig at leverandøren har gode rutiner for versjonshåndtering, slik at det kan lages brancher med nødvendige feilkorrigeringer. 4.10 Runtime versjoner Det skal kun brukes siste «stable/final release» av.net og eventuelle andre utviklingsverktøy. Dersom dette skal fravikes må dette begrunnes og avklares. 4.11 Universell utforming Løsninger som har eksterne brukere må oppfylle krav til universell utforming. Forskrift om universell utforming av IKT-løsninger stiller krav om at nettsider må oppfylle 35 av 61 suksesskriteriene i standarden Retningslinjer for tilgjengelig webinnhold (WCAG) 2.0. Det må være enkelt for innholdsleverandør/webredaktør å ivareta kravene til universell ved produksjon/publisering av innhold. 4.12 Planleggingsverktøy Som system for planlegging, feilhåndtering og oppfølging bruker Miljødirektoratet JIRA (atlassian.com). Dette er det interne prefererte verktøyet. Skal JIRA benyttes bes Miljødirektoratets JIRA instans benytte. For mindre prosjekter kan GitHub sitt integrerte verktøy benyttes. Side 8 av 8