altinn / altinn-broker Goto Github PK

Description

Hvilke ressurser får vi internt og eksternt?

In scope

No response

Out of scope

No response

Additional Information

No response

Analysis

No response

Conclusion

No response

Description

Deler innsikt med PG

Additional Information

No response

Tasks

• Mappesystem for dokumenter i teams-området til PG meldingsutveksling

Acceptance Criterias

No response

Gjennomgang av dialogporten og hva som tenkes rundt den og påvirkning/sammenheng med meldingsutveksling.

Konseptvalg må forankres med data.altinn, dialogporten, sjefsarkitekt og ev. eFormidling. Dette gjøres med løpende dialog, workshops, og et formelt forankringspunkt ved konseptvalg.

Avklaring med data.altinn på hvilke behov som innfris av data.altinn og hva som løses av altinn formidling.

• Oppsummere innsikt, nåsituasjon, tjenester (bruksmønster)
• Organisere møte med DAN-teamet hvor vi ser på muligheter og utfordringer
• Avrunde med en tydeliggjort grensegang mellom DAN og formidling.

Se bla mail fra Oddhild, tidligere DPIA.

Vi må få avklart hva vi har ansvar for og om vi har det behandlingsgrunnlaget som trengs. I tillegg bør vi gå i dialog med spes. politiet og muligvis også Helse-møre (som er potensiell ny kunde) for å avklare hvorvidt de har gjort egne vurderinger, eller når de planlegger å gjøre det. Et mulig utfall er at vi må vurdere å tilby alternativ lagring til azure for de tjenester som handterer data som vurderes som mindre egnet for offentlig sky. Se også NSM sine anbefalinger knyttet til nasjonal sky. Håper vi kan starte med å få gjort en innledende vurdering/kartlegging som kan ligge til grunn når vi skal begynne å tenke på løsningskonsepter i neste sprint.

Forankre konsept

Description

Grundig gjennomgang av Correspondence og Broker, Feks: hva er viktige avhengigheter i migreringen?

In scope

No response

Out of scope

No response

Additional Information

No response

Analysis

No response

Conclusion

No response

Beskrive as is inkl relevante omgivelser som grunnlag for målbilde og overgangsarkitektur.

Modellen er produsert (se lenke i kommentarer). Gjenstår avklaring av hvor den skal bo i fortsettelsen.

Overgang til maskinporten, autorisasjon/SRR, apis, osvosv.

Kan leveres inn i exceloversikt?

Steinar kaller inn - gjennomgang av eFormidling - arkitektur

Funksjonelt og teknisk. - en del av å forstå og kartlegge as-is.
har i praksis 2 tjenester
Gjennomgang for teamet tilbys.

Question

Synes det er litt uklart hva "who" parameteret er i sammenheng med formidlingstjenesten opplasting og nedlasting av filer. I dokumentasjonen for meldingsboks "who":

"'my', or an organization number of an organization the user can represent, or <Reportee.ReporteeId>, where the identified reportee may be a person or organization."

Mens i dokumentasjonen for BrokerService står det litt uklart flere beskrivelser:

For meg virker det som om who skal være enten org nummer på mottaker i formidlingstjenesten eller org.nr/pers.nr for avsender av filen som lastes opp, kan noen forklare hva verdien til dette parameteret skal være?

Vi bør ha detaljert oversikt på hvilke features som faktisk er i bruk og av hvilken tjeneste.

Kan legges til i exceloversikt pr. tjeneste https://digdir.sharepoint.com/:x:/r/sites/PGMeldingsutveksling/Delte%20dokumenter/General/Altinn%20migrering/Formidling/Innsikt%20og%20intervjuer/Samlet%20oversikt%20over%20prosessene.xlsx?d=w38cb4cf1a9db431087e3f0a86a40bbb9&csf=1&web=1&e=CqdXJo

Description

test

Additional Information

No response

Tasks

No response

Acceptance Criterias

No response

Gjennomgang (og oppsummering) av innsikt så langt.

Innsikt bør oppsummeres i behovshypoteser som kan legges til grunn i målformuleringsarbeidet, og i utviklingen av løsningskonsepter.

Trenger avklaring på hvordan epics formuleres, på hvilket nivå de ligger (kapabilitet?), og selve formuleringen.

Hvordan dokumenterer vi, deler informasjon i teamet, med andre team og eksterne. Bruk av github, slack og teams i skjønn forening. Hvordan handterer vi support-issues og støtte til nye tjenesteeiere? Hvilke roller og kompetanse trenger vi på teamet fremover.

POC Maskinporten/Altinn aut. Som alt. Til SRR (Ragnar/Tom Sverre)

POC Kompetansebygging
Lese dokumentasjon
Gjennomgang
Identifisere hvem som kan bistå
Kjøre gjennomgang
Analyse med
Valg av case
Utkast til løsningsforslag
Plan for arbeid med POC
Utføre POC/tester

Vi trenger en kortfattet oppsummering vi kan bruke ovenfor andre teams, eksterne ol.
Ser for meg disposisjon:

• hva er formidlingstjenesten
• Hvilke tjenester kjører på den, volum, og bruksmønster
• Hvilke kapabiliteter benyttes, med fokus på andre produkter som innboks, lagring, varsling og autorisasjon
• Identifiserte problemområder i dag

Denne presentasjonen kan så bygges videre på med løsningshypoteser, produktmål, migreringsplan osv.

Altså: en slags masterpresentasjon for formidlingstjenesten.

Description

Gjennomføre intervjuer med tjenesteeire for oversikt over hvordan tjenestene brukes i dag og hvordan de ønsker å jobbe i fremtiden. Danner grunnlag for hvilken retning vi velger å gå i når tjenesten skal migreres/dekomponeres.

In scope

• Lage liste med kontaktpersoner
• Onboarding av Camilla
• Spisse spørsmål i intervjuguide - hva trenger vi egentlig å vite?
• Booke møter
• [ ]

Out of scope

No response

Additional Information

No response

Analysis

No response

Conclusion

No response

https://docs.altinn.studio/technology/architecture/requirements/non_functional/

Description

Hva vil det innebære å flytte løsningen "as is" over i sky?

In scope

No response

Out of scope

No response

Additional Information

Inkrementell analyse

Analysis

No response

Conclusion

BrokerISkyFigur.V3.pptx
BrokerISkyV3.xlsx
RFT27618 - Formidling i sky.docx

Neste runde intervjuer hvor vi går litt mer konkret løs:
En litt mer teknisk og praktisk orientert guide som kan bidra til at vi får svar på:
Tjenesteiers vilje og evne til å utføre endringer på sin side ifbm migrering
Tekniske forutsetninger og ønsker (feks. knyttet til apiene)
Bør vi ha med oss behovshypoteser og løsningsalternativer inn?
Identifisere aktører vi ikke har snakket med enda som bør med i denne fasen.

som kan "utfordre" eller stressteste Hennings løsningsforslag. Se på fremoverkompabilitet.
Feks.
Kan formidling være en gjenbrukbar "studio-app" hvor vi lager mvp, og aktiviserer A3 communityet i videre arbeid?
Kan integrasjon og "varsling" løses gjennom dialogporten?
Kan eFormidling spille en rolle?
Kan formidlingstjenesten sine tjenester flyttes til data.altinn?

Avklare form og innhold med HansO/styringsteam

DOD: Samle og oppsummere sikkerhetsvurdering, juridisk vurdering og risikoregister i et notat som anbefaler veien videre.

Ting å vurdere:
Store filer/volum
sikkerhet/sporbarhet
maskin til maskin
fleksibilitet

Bør baseres på overordnede målsetninger, det vi vet om PG strategi, kjente behov osv.

Som team trenger vi felles mål å jobbe mot, for å kunne prioritere riktig, og levere konsept, planlegging og MVP på tid og kost.

Tom Sverre: Analyse av trafikk, konfigurasjon/oppsett pr tjeneste.
Kombinasjon av uttrekk fra TUL/serviceengine, statistikk, ++

Dette for å sikre at vi forstår likheter og ulikheter knyttet til tjenestene og kan vurdere riktig fremtidsløsning.

Tjenesteeiere +++
Mål med møtet - presentere det vi har gjort i sprint og få tilbakemeldinger på det umiddelbart.

Store filer min 15 GB. -10000+ forsendelser/år:
Konsumenter/mottakere: både personer og virksomheter (pasienter, pårørende (helse norge), forsikring, NPE osv..)
Drag and drop fra eboks og velge mottaker fra altinn.
Virusscan før opplasting og nedlasting
Handtering av samtykker
Videredeling
Visningskilent – Dicon viewer mulig å integrere.
Sporbarhet – arkiv
Tidsbegrenset lagring
2-veis
Nøkler på SMS

MVP: slutte å sende minnepinner pr. Brev.
Sikkerhet: normen.
Varsling
Generisk – flere som ønsker det samme innenfor helse-midt
Mulige løsningskomponenter som bør vurderes:
Helsenett/helsenorge/HEMIT - integrasjon?
Dialogporten (bjørn)
Altinn formidling/eformidling
Samtykke/autorisasjon (siv/espen)
Studio? (finnur/eirik)
Tjenesteeierstyrt rettighetsregister? (siv/espen)
Maskinporten? (jørgen)
Data.altinn.no (erlend)

Oppfølging:
John sender over funksjonelle og ikke-funksjonelle krav for MVP.
Vi (steinar/erik) lager en løsningsskisse
Nytt møte 17 april e kl 12

Description

• kjihj
• lnkln
• lnlkn

In scope

No response

Out of scope

No response

Additional Information

No response

Tasks

No response

Innhold og praktisk gjennomføring må planlegges.

• Info om reisebestilling
• Hvem er med

Dokumentasjonen (på https://docs.altinn.studio) må oppdateres både på kort og lang sikt. Det første innholdet som må på plass er mer korrekte datoer både når det gjelder migrering og utvikling.

Dette skal også være stedet for brukerdokumentasjon og systemdokumentasjon. Vi må tidlig bygge rammeverket for dette.
Grunnleggende kunnskap i markdown og bruk av git, er et must for å komme i gang.

===============================
Fra Siv - kunne du gått inn på denne siden og sett på hva som står om migreringsstrategi for meldingstjeneste og formidlingstjeneste (https://docs.altinn.studio/authorization/migration/servicemigrationplan/#meldingstjenester) og https://docs.altinn.studio/authorization/migration/servicemigrationplan/#formidlingstjenester. Det som står skrevet nå er noe jeg "gjettet" i november 2022 - antagelig kan det oppdateres med annen informasjon nå.

I forbindelse med faseovergang fra konsept til plan, i porteføljeprosessen, må det foreligge en overodnet juridisk vurdering av konseptalternativene.

Den foreløpige juridiske vurderingen er tilgjengelig i Teams. Før den juridiske vurderingen kan ferdigstilles må det foreligge skriftlig dokumentasjon av konseptet, inkl arkitekturskisser med tilhørende dokumentasjon.

https://github.com/orgs/digdir/projects/8/views/5?filterQuery=

Vi trenger en samlet oversikt over de ressursene teamet forvalter, være seg docs, backlogger, pekere til andre styringsparametre som feks arkitekturprinsipper ol. Begrepsdefinisjoner bør også inngå her.

Vi trenger denne for å løfte oss selv og hverandre på teamets produkter, og for å gjøre det enkelt å onboarde nye ressurser i fremtiden.

Bør omfatte både Altinn 2 og 3

Description

Avhengigheter og anvar ifbm overlapp med produkter/ansvarsområder til Snorre, Reidun og Finnur

In scope

No response

Out of scope

No response

Additional Information

No response

Analysis

No response

Conclusion

No response