Retning for Teknologi

Løse koblinger resulterer i høyere fleksibilitet av løsninger vi utvikler. Forskningen viser at asynkron tilnærming gir økt effektivitet generelt og gir høyere kvalitet av data og informasjonsdeling. Samtidig gir asynkronitet mulighet til å forenkle skalering for prosessering av data.

Det vi ønsker å oppnå er meningsfull kommunikasjon mellom systemer og kommunikasjon (according to their patterns) kan være både synkron og asynkron. Begge kommunikasjons-mønstrer er i bruk i dag, men vi velger å fokusere oss mer på den andre (dvs. asynkron) fordi den gir oss en del muligheter for å adressere hierarkisk sett høyere funksjoner.

Et datadrevet politi bruker systematisk innsamling, analyse og tolkning av data for å styre sin strategiske og operative beslutningstaking. Ved å basere beslutninger på objektive og relevante data kan virksomheten oppnå store fordeler.

Implementering av et datadrevet prinsipp krever:

• Kvalitetsdata: Vi må sikre at data som samles inn er av høy kvalitet, relevante og pålitelige.
• Kultur og kompetanse: Vi må utvikle en kultur der data verdsettes, og ansatte har nødvendig kompetanse til å analysere og tolke data.
• Data i sentrum: Vi vil bevege oss fra å være applikasjonssentrert til å bli datasentert. Dette betyr at måten som vi håndterer data på også må endres, fra å være begrenset av applikasjonens rammer til å være fritt tilgjengelig som et produkt med spesifikke egenskaper. Det er dataene som skaper langsiktig verdi, og applikasjonene eksisterer kun for å behandle og forbedre dataene.
• Data må være FAIR (Findable, Accessible, Interoperable og Reusable): Fair Guiding Principles er prinsipper som fokuserer på maskinhåndtering av data slik at maskiner kan finne, få tilgang til, se data i sammenheng, og gjenbruke data uten kostbare spesialintegrasjoner.

Data som et produkt

Valg av asynkron kommunikasjons-mønster gir oss bedre mulighet å definere "Data som et produkt". Det gir oss:

1. økt datakvalitet i våre og andre systemer
2. gir mulighet for sammenstilling av data som gir mer verdi
3. gir oversikt over data (i tilfelle at vi ønsker å bli datadrevet - noe vi definitivt har lyst på)
4. gir oversikt om eierskap og ansvar
5. inneholder meta-informasjon som beskriver data og gir sammenhengen de er samlet inn i, som blant annet lover og hjemler

Data katalog

Nå sitter vi med data som er isolert (mtp løs kobling mønster), av høy kvalitet og hentet eller produsert i en bestemt kontekst i form av data som et produkt.

Nå må vi tilgjengeliggjøre data til konsumenter. Derfor trenger vi data katalog for å finne frem til hvilken data finnes hvor, hvem man kan kontakte og hvilke forutsetninger man har for å kunne ta i bruk dataen.

1. data som kan deles fra systemer bør beskrives i datakatalog
2. Datakatalog inneholder informasjon om data som et produkt
3. Den inneholder også informasjon om synkrone dataset (altså de som ikke er egnet for å være asynkrone) fordi det finnes en mange data sets som ikke er egnet for asynkronitet.

Data mesh

Nå er data åpnet og demokratisert (det vil si tilgengliggjort), og da er det nødvendig å desentralisere den. Desentralisering er nødvendig for å fjerne flaskehals i form av store databaser eller andre type lagring. La oss se på det som etablering av mikrotjenester for data.

Data mesh utnytter prinsippene for domene orientert design for å levere en selvbetjent dataplattform som gir mulighet til brukere å abstrahere den tekniske kompleksiteten og fokusere på deres individuelle databrukstilfeller. For å muliggjøre samarbeid på tvers av domener, må data mesh standardisere formatering, styring, oppdagbarhet og metadatafelt, blant andre datafunksjoner. Dessuten, omtrent som en individuell mikrotjeneste, må hvert datadomene definere og bli enige om SLAer og kvalitetsmål som de vil "garantere" til forbrukerne

Sikkerhetsfunksjoner bygges inn i alle lag av en løsning, noe som legger et større ansvar på teamene som kjenner løsningen best, og understøtter økt autonomi.

Ved å bygge sikkerhetsfunksjoner direkte inn i løsninger, benytte økt grad av standardisering, og i mindre grad være avhengig av perimetre som kontrolleres av andre så vil en raskere kunne etablere service mesh mellom forskjellige løsninger.

Helhetlig sikkerhetsmodell

For en del tekniske behov har vi i dag laget mange forskjellige løsninger, eksempelvis for overføring av filer fra en sikkerhetssone til en annen. Ved å standardisere en del funksjoner kan vi redusere kompleksitet og mulighet for feil, samt øke evnen for observability.

En helhetlig sikkerhetsmodell vil også gjøre det enklere å lage løsninger som kan benytte ressurser fra både sky og egne datasentre, samt gjøre det enklere å flytte en løsning fra en driftsplattform til en annen.

Ved å ha tydelige felles modeller blir det lettere å gjøre ting rettere, og vi øker samtidig sikkerheten.

Målinger av endringsevne og kvalitet

Løsningen(e) må understøtte nødvendig endringsdyktighet og kort leveringstid for ytterligere funksjonalitet. Ad-hoc unøyaktige målinger og rapportering av ferdiggrad gir oss ingen indikatorer på om vi har en endringsevne og om vi leverer kvalitet. Konseptet "observability" ligger til grunn for dette.

Det er tre pilarer som ligger til grunn for dette:

• LogEvents
• Metrics
• Traces

Motstandsdyktige systemer

Våre systemer, og særlig de som understøtter politiets operasjonelle evne, må ha høy oppetid og tilgjengelighet. De må derfor være motstandsdyktige (resilient) mot trusler som høy belastning, villet eller ikke, og angrep mot vår infrastruktur.

Dette innebærer følgende punkter:

Redundans

Systemene våre skal ha tilstrekkelig redundans, både geografisk og i antall instanser, for å oppfylle tilgjengelighetskravet for systemet.

Dynamisk opp- og nedskalering

Ved endringer i belastningen på systemene skal kapasiteten justeres tilsvarende, for å sikre gode svartider og ytelse. Cloud native-prinsippene tilsier at systemene skal designes på en slik måte at opp- og nedskaleringen skjer automatisk.

Automatisk feilhåndtering

Systemene våre må være motstandsdyktige mot feilsituasjoner, både interne bugs og nedetid i eksterne avhengigheter. I tillegg til redundans må de derfor ha feilhåndteringsmekanismer slik som automatisk failover, og selv-reparerende egenskaper som f.eks retry-mekanismer og circuit breakers.

Disse mekanismene hjelper til med å minimere nedetid, og sikre høy tilgjengelighet.

Testing og kvalitet

1. gjennomføres i hele utviklingsprosessen, fra behov til produksjonssatt kode
2. tilrettelegge for at funksjonalitet og tekniske endringer kan produksjonsettes kontinuerlig
3. automatisere tester så tidlig som mulig i utviklingen av en brukerhistorie. Det skal være flest tester på komponentnivå
4. redusere risiko ved at automatiske komponenttester har høy testdekning og kjøres ved hver endring
5. automatisere tester av brukernes arbeidsflyter i ende-til-ende-tester
6. teste manuelt når det er behov for det
7. bygge tillit til at løsningen kan håndtere avvikssituasjoner

Bruk av skytjenester lar oss realisere løsninger raskere (SaaS som f.eks administrative systemer).

Vi får tilgang på innovasjon som kan gjøre løsningene våre bedre.

Vi reduserer utbyggingsbehovet for egne datasentre (Kan heller øke kvaliteten på de datasenter-tjenestene vi tilbyr).

Containere, service mesh, mikrotjenester, immutable infrastructure og deklarative API-er eksemplifiserer denne tilnærmingen. Disse teknikkene muliggjør løst koblede systemer som er "resilient, managable and observable". Kombinert med robust automatisering gjør de (teknikkene) det mulig for ingeniører å gjøre store endringer ofte og forutsigbart med minimalt av hindringer.