Design

Systemskisser

Det er viktig med et godt underlag når vi skal bygge gode løsninger, og skisser og diagrammer som viser oppbygningen av infrastruktur, dataflyt, nettverk og tilgangsstyring er viktige elementer. Uten denne informasjonen er det vanskelig å validere om sluttresultatet matcher intensjonen.
Sist endret 26.10.2026 Skrevet av Christoffer Hafsahl og Andreas Skaret
Skriv ut hele seksjonen

Når vi designer en løsning, er det viktig med gode og oversiktlige skisser og diagrammer som viser designet slik at det planlagt. Dette gjøres allerede av mange utviklerteam uten at det nødvendigvis stilles krav til det, men det er likevel greit å nevne her.

Systemskissene bør gi nok informasjon til at en i etterkant kan

  • Validere at implementasjonen er som designet
  • Bruke dem ifm trusselmodellering, pentesting eller liknende
  • Brukes av den/de som forvalter løsningen for å få en god oversikt over komponenter og dataflyt
  • Brukes av leveranseteamet for onboarding av nye kollegaer eller handover til andre team.

Selv om det er mye som kan dokumenteres her, fokuserer vi bare på det viktigste her:

  • Overordnet systemskisse med de viktigste logiske komponentene
  • Detaljert nettverksskisse med ressurser, tjenester og nettverk
  • Dataflytdiagram viser hvordan data flyter mellom komponenter i løsningen
  • IAM-diagram viser identiteter, tilganger og roller samt hvor de hentes fra
  • Viktige avhengigheter viser oversikt over andre systemer, tjenester, ressurser, onprem/cloud

Bruk av KI-komponenter

Dersom løsningen inneholder kunstig intelligens eller maskinlæring-modeller, må disse være eksplisitt dokumentert i systemdokumentasjonen:

  • I dataflytdiagrammet: Viser hvor treningsdata og inferensinput kommer fra, og hvordan resultater flyter videre
  • I nettverksdiagrammet: Dokumenter hvor modellen kjører (cloud API, edge device, on-prem server) og nettverkskonnektivitet
  • I avhengighetslisten: Eierskap av modeller, versjonering, og hvor de oppdateres
  • I IAM-diagrammet: Hvem kan deploye, oppdate eller monitorere modellen

Uten denne informasjonen er det vanskelig å få oversikt over risiko, dataflyt og compliance rundt AI-komponenter.

Eksempler

Under finner du eksempler på punktene listet ovenfor. Diagrammene du produserer trenger ikke å være like, det viktigste er at de inneholder nok informasjon til at de kan brukes for det tiltenkte formålet og at de er forståelige for teamet.

For enkelt å komme igang med design av diagrammer og skisser kan verktøy som Miro eller Draw.io brukes. Sistnevnte er gratis og tilbyr lagring av tegniner i nettleser, lokalt på maskinen som XML og mye annet.

Husk

Diagrammene trenger ikke å være perfekte, eller inneholde alle tenkelige detaljer. Vurder behovet og jobb med gradvise forbedringer over tid.

Overordnet systemskisse

Den overordnede systemskissen viser de viktigste komponentene, og hvordan disse forholder seg til hverandre. Viktige avhengigheter merkes, slik at det er lett å få et overblikk over systemene.

Overordnet systemskisse Frontend snakker med Backend. Backend henter data fra to databaser, On-prem SQL og Azure SQL, og utveksler data med bedriftens dataplattform, som er en avhengighet utenfor løsningen. Backend leverer også data til Power BI Reports, som i tillegg henter fra dataplattformen. Frontend Backend Power BI Reports Bedriftens dataplattform (avhengighet) On-prem SQL Azure SQL
Eksempel på overordnet systemskisse. Den viser bare de største komponentene og hvordan de henger sammen. Avhengigheter utenfor løsningen er stiplet, slik at det er lett å se hva teamet selv rår over.

Netverksdiagram

Målet med nettverksdiagrammet er å vise topologien, med alle virtuelle nettverk, subnett og ressurser og åpninger mellom disse. Et godt nettverksdiagram viser flyten mellom tjenester og enheter, slik at andre involverte kan danne seg et bilde av hvordan data flyter fra punkt til punkt.

Nettverksdiagram for et utviklingsmiljø En intern bruker når en Azure Firewall over HTTPS 443. Brannmuren slipper trafikk videre til subnettet Frontend-dev (10.0.0.0/27), som inneholder en app service og en key vault, og til rapportområdet Dev workspace med to rapporter. Begge går videre til en Azure WAF, som slipper trafikken inn i subnettet Backend-dev (10.0.0.32/27). Der ligger to app services og en ingress-factory, som alle bruker den samme SQL-databasen og key vaulten. Ingress-factory henter data fra datasjøen datalake-somedata-prod01 i bedriftens dataplattform, som ligger utenfor miljøet. Intern bruker HTTPS 443 Azure Firewall Frontend-dev 10.0.0.0/27 frontend-dev-appsvc 10.0.0.2 frontend-dev-keyvault Dev workspace Rapport 1 Rapport 2 HTTPS 443 HTTPS 443 Azure WAF HTTPS 443 Backend-dev 10.0.0.32/27 backend-dev-appsvc01 10.0.0.36 backend-dev-appsvc02 10.0.0.37 ingress-factory-dev-01 10.0.0.43 backend-dev-sql01 10.0.0.40 backend-dev-keyvault 10.0.0.50 HTTPS 443 Bedriftens dataplattform (avhengighet) datalake-somedata-prod01 10.10.10.10
Eksempel på nettverksdiagram for et utviklingsmiljø. Hvert subnett er navngitt med adresseområdet sitt, hver ressurs har sin egen adresse, og pilene viser retningen på trafikken og hvilken port som er åpnet. Rapportområdet når backend-API-et gjennom samme WAF som frontenden. Den stiplede boksen er en avhengighet utenfor teamets eget miljø.
Husk:

Nettverksdiagram bør lages for alle miljø, slik at en får nødvendig informasjon på alle ressurser i alle miljø, samt forbindelser mellom disse.

Dataflytdiagram

Dataflytdiagrammet fokuserer primært på datakildene, og viser hvordan data flyter gjennom systemet. En kan også inkludere overordnet informasjon om hvordan data transformeres eller modifiseres, slik at det er enklere å gå opp eventuelle avvik i etterkant.

Dataflytdiagram for et utviklingsmiljø Dataene kommer fra to kilder: databasen production-sql-01 på egen maskinpark, der tre views er i bruk, og containeren datalake-somedata-prod01 i bedriftens dataplattform. Begge lastes inn av ingest-factory-dev-01, som kjører fire pipelines. Derfra skrives dataene til skjemaene CurrentData og HistoricalData i backend-dev-sql01. HistoricalData leses av Report01 og Report02 i dev-workspace, CurrentData av Report03. Kilder production-sql-01 on-prem Views i bruk v_get_all_production_data v_get_production_summary_12mth v_get_products_info Bedriftens dataplattform (avhengighet) Container datalake-somedata-prod01/ production-data-container Innlasting ingest-factory-dev-01 Pipelines Copy_production_data Kopierer produksjonsdata Update_production_summary Oppdaterer sammendraget Refresh_products_info Oppdaterer produktindeksen Copy_datalake_data Henter data fra datasjøen Lagring backend-dev-sql01 Skjemaer CurrentData HistoricalData Rapportering dev-workspace Rapporter Report01 Report02 Report03
Eksempel på dataflytdiagram. Det følger dataene fra kilde til rapport, og navngir hvilke views, pipelines og skjemaer som faktisk er i bruk i hvert steg. Det er den navngivingen som gjør diagrammet brukbart når et avvik skal spores tilbake.

IAM-diagram

Et IAM-diagram beskriver hvor brukerne kommer ifra, og hvilke roller som tildeles brukere og eventuelt tjenester eller enheter på de ulike ressursene.

IAM-diagram for et utviklingsmiljø Til venstre ligger identitetene i Entra ID: en tjenesteprinsipal for Azure DevOps, de administrerte identitetene til Backend og ingest-factory, en utvikler og en applikasjonsbruker. Til høyre ligger Dev Subscription med ressursene backend-dev-sql01, dev-keyvault og ressursgruppene Backend og Frontend, samt production-sql-01 som står på egen maskinpark utenfor abonnementet. Tjenesteprinsipalen er Owner på abonnementet og utvikleren Contributor. Utvikleren er i tillegg Key Vault Secrets Officer på dev-keyvault og SQL Admin på både backend-dev-sql01 og production-sql-01. De administrerte identitetene er Key Vault Secrets User på dev-keyvault og db_datareader på backend-dev-sql01. Applikasjonsbrukeren har en brukerrolle på Frontend. Entra ID Brukere og tjenesteprinsipaler Dev Subscription Abonnement Owner Contributor SQL Admin db_datareader Key Vault Secrets Officer Key Vault Secrets User Brukerrolle SQL Admin Tjenesteprinsipal Azure DevOps Administrerte identiteter Backend, ingest-factory Utvikler Applikasjonsbruker backend-dev-sql01 Azure SQL dev-keyvault Key Vault Backend Ressursgruppe Frontend Ressursgruppe production-sql-01 On-prem, utenfor abonnementet
Eksempel på IAM-diagram. Identitetene står til venstre, omfangene til høyre, og hver pil er én rolletildeling med rollenavnet påskrevet. Piler som ender på kanten av abonnementsboksen er tildelt på abonnementsnivå og arves ned til alt som ligger i det; piler som ender på en ressurs gjelder bare den ressursen. Poenget er at ingen tilgang står udokumentert.

Avhengigheter

Dette kan tegnes som et diagram, men kan like gjerne være i form av en enkel liste. Denne oversikten bør beskrive alle direkte avhengigheter for prosjektet, med et kort sammendrag av hvordan den brukes og hvorfor.

  • On-prem databaseserver production-sql-01
    • Bruker tre view vedlikeholdt av teamet
    • Data hentes inn via ADF
  • Selskapets dataplattform, datalake datalake-somedata-prod01
    • Konsumerer datasett i containeren production-data-container
    • Lineage er synlig i Purview
    • Bruker kun datasett godkjent av dataeier

Veien videre