Personer med ansvar for IT-arkitektur bør etterstrebe å fungere som brobyggere mellom forskjellige lag i organisasjonen. Figuren under viser hvordan arkitekter kan fungere som brobyggere i organisasjonen.
Domenemodeller for klassifisering
Modellene under setter begreper i sammenheng og vil gjøre det lettere å forstå hverandre i kommunikasjon omkring IT-løsninger.
Sjekkliste for arkitekturarbeid i prosjekter
Er arkitekter og arkitekturressurs til prosjektet identifisert?
Er relevante arkitekturprinsipper for prosjektet identifisert?
Er hoved arkitekturbeslutninger basert på systematisk og pragmatisk metode? Sjekke Katalog over arkitekturdrivere.
Er hoved arkitekturbeslutninger i prosjektet logget? Beslutningslogg Mal
Sørge at Arkitekturråd godkjente valgte arkitekturbeslutninger og er i tråd med TK arkitekturvisjon og prinsipper.
Vurdering av personvernkonsekvens (minimum initiell vurdering)
Forretningsbehov:
Er ulike kategorier av brukere kartlagt?
Er forretningsprosesser/ forretningstjenester kartlagt? (eksempel)
Er revurdere nåværende prosesser (As-Is, To-Be og gap analyseanalysere) kartlagt? (Prinsipp F-1)
Er relevante felles prosesskrav identifisert?
Applikasjon og Informasjon:
Er eksisterende Kommune og nasjonal applikasjonskomponenter som kan gjenbrukes identifisert?
Er generelle integrasjoner til eksisterende og ikke-eksisterende app-komponenter identifisert?
Er eksisterende master datakilder identifisert? (dsv. Det sentrale folkeregister)
Er generelle integrasjoner kartlagt?
Sikkerhet
Gjennomføring av ROS-analyse som grunnlag for krav
Mal for Databehandleravtale
Se også egen site om risikovurdering og internkontroll.
Applikasjon og Informasjonsbehov:
Er domenemodell (data objekter og relasjoner) utarbeidet? (eksempel)
Er ulike typer av data kartlagt? (masterdata, transaskjonsdata, referansedata osv.)
Er detaljert integrasjonskrav til TIP team dokumentert? (se Mal)
Er relevante felles produktfunksjonalitet identifisert?
Er funksjonellekrav til ikke-eksisterende app-komponenter utarbeidet?
Er relevante kvalitetskrav identifisert?
Er generelle integrasjoner kartlagt?
Er relevante felles prosesskrav identifisert?
Ved behov, oppdater
Forretningsbehov
Sørge at alle krav (funksjonelle og kvalitetsskrav) dokumenteres på ett sted (verktøy som Jama skal brukes), og har Krav-ID som kan refereres til i andre dokumenter.
Test
Mal for Testbare krav
Krav til leverandørens teststrategi
Ved behov, oppdater
Forretningsbehov, Applikasjon og Informasjonsbehov
Detaljert integrasjonskrav
API mal i samarbeid med leverandør
Fullfør skjemaene nedenfor i samarbeid med leverandør, løsningsarkitekt og tjenesteforvalter:
Test
Evaluering
I alle tilfeller der fasit er rød skal prosjektleder gi en skriftlig begrunnelse. Begrunnelsen sendes til prosjektets styringsgruppe.
I tilfeller der fasit er oransje, kan ikke Løsningsarkitekten/IT-arkitekten ta fullt ansvar for valgene. Prosjektleder må redegjøre hvorfor rutinene om å involvere arkitekter på et tidlig nok tidspunkt ikke er blitt fulgt. Begrunnelsen sendes til prosjektets styringsgruppe.
I tilfeller der fasit er gul eller grønn, kan Løsningsarkitekten/IT-arkitekten ta ansvar for valgene.
Modenhetsmålinger