Tidligere refererte repoet til dokumentasjon som lå utenfor (i Salg/_mal/), og brukte Obsidian-wikilinks [[...]] som ikke er klikkbare i Gitea. Begge deler gjorde at lenker var døde i Gitea-web. Endringer: - Hentet inn arbeidsdokumentene som faktisk brukes under oppdraget: _metode/ (00-konvensjoner, 01-startklar-sjekkliste, 02-gjennomforing) artefakter/ (risikoregister, integrasjonslandskap, workshop-agenda, domenemodell-skjema) - Konverterte 82 Obsidian-wikilinks til standard markdown-lenker med korrekte relative stier — klikkbare både i Gitea og lokalt - Begrepsord i begrepskatalogen ([[Bedrift]] etc.) ble til ren tekst (de var aldri filer) - Oppdaterte konvensjonsdokumentet til å foreskrive standard markdown, ikke wikilinks (med begrunnelse: Gitea rendrer ikke [[...]]) - Oras/Kirken/salgsmateriale er nå tydelig merket som eksterne arbeidsområde-referanser (andre kunder / salgsfase), ikke dinglende lenker som lot som de var i repoet Verifisert: 133 ekte interne lenker resolver korrekt. De 4 gjenværende treffene i validering er kodeeksempler i backticks (viser lenke-syntaks), ikke faktiske lenker. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
67 lines
1.8 KiB
Markdown
67 lines
1.8 KiB
Markdown
---
|
|
title: "Integrasjonslandskap — <KUNDE>"
|
|
date: "YYYY-MM-DD"
|
|
tags: ["integrasjon", "landskap", "artefakt"]
|
|
qa:
|
|
status: "draft"
|
|
version: 1
|
|
---
|
|
|
|
# Integrasjonslandskap
|
|
|
|
Strukturert oversikt over alle integrasjoner. Mønster fra Oras Group sin Data Health Assessment (seksjon 6).
|
|
|
|
## Per system / integrasjon
|
|
|
|
| System | Retning | Kilde / motpart | Mekanisme | Datatyper | Frekvens | Personopplysninger? | Migrasjons-/endringsimplikasjon |
|
|
|---|---|---|---|---|---|---|---|
|
|
|
|
**Retning:**
|
|
- **Inbound** — kommer inn til system
|
|
- **Outbound** — går ut fra system
|
|
- **Bidirectional** — toveis
|
|
|
|
**Mekanisme:**
|
|
- REST API
|
|
- GraphQL
|
|
- SOAP
|
|
- Event/message bus
|
|
- Filoverføring (SFTP/batch)
|
|
- Database-til-database
|
|
- Manuell (Excel-eksport, etc.)
|
|
- ETL/ELT-jobb
|
|
|
|
**Frekvens:** Real-time / Hver time / Daglig / Ukentlig / Månedlig / Ad hoc
|
|
|
|
## Kritisk-vurdering
|
|
|
|
For hver integrasjon, vurder:
|
|
|
|
| Spørsmål | Hvis ja: konsekvens |
|
|
|---|---|
|
|
| Brytes ved skifte av motpart? | Må redesignes |
|
|
| Inneholder personopplysninger? | GDPR-vurdering kreves |
|
|
| Cross-border? | DPA/SCC kreves |
|
|
| Real-time vs. batch? | Påvirker arkitekturvalg |
|
|
| Blokkerende ved feil? | Resiliens-tiltak nødvendig |
|
|
|
|
## Endringer som påvirker landskapet
|
|
|
|
*Pågående initiativer hos kunden som vil endre integrasjonsbildet. Lenke til [pagaende-initiativer](../3.system-og-datalandskap/pagaende-initiativer.md).*
|
|
|
|
## Punkt-til-punkt vs. hub-and-spoke
|
|
|
|
Antall integrasjoner i dag: **N**
|
|
|
|
Vurdering: Er antallet håndterbart, eller bør vi vurdere å konsolidere via integrasjonsplattform (hub-and-spoke)?
|
|
|
|
**Vurderingskriterier:**
|
|
- Antall punkt-til-punkt-integrasjoner (>15-20 begynner å bli vanskelig)
|
|
- Vedlikeholdskostnad
|
|
- Nye systemer som skal kobles på
|
|
- Behov for sentral logging og styring
|
|
|
|
---
|
|
|
|
*Klassifisering: Begrenset*
|