Same bulk replacement applied to plugin-internal KB, examples, fixtures, tests, and docs. Real organization names, persona names, internal system identifiers, and domain-specific terms replaced with fictional generic public-sector entity (DDT) and generic terminology. Scope: - okr/ — examples, governance, framework, integrations, sources - ms-ai-architect/ — KB references (engineering, governance, security, infrastructure, advisor), tests/fixtures, agents, docs - linkedin-thought-leadership/ — voice samples, network-builder, examples (genericized identifying headlines to "[your organization]") - llm-security/ — research notes, scan report Manual genericization beyond bulk replace: - okr SKILL.md "Primary user / Domain" — generic Norwegian public sector - linkedin-voice SKILL.md headline placeholder - network-builder.md headline placeholder - high-engagement-posts.md voice sample employer line + hashtag Phase 3 (factual-attribution review) remains: a few KB files attribute publicly known transport-sector docs/datasets (e.g. håndbok V440, NVDB) to the fictional DDT after bulk replace. Needs manual semantic review to either remove or restore correct citation without re-introducing affiliation references. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
15 KiB
Data Mesh Patterns and Domain Ownership
Last updated: 2026-02 Status: GA Category: Data Engineering for AI
Introduksjon
Data mesh er en desentralisert dataarkitektur som organiserer data etter forretningsdomener i stedet for sentraliserte datateam. Prinsippene -- domeneeierskap, data som produkt, selvbetjeningsplattform og foderert styring -- er spesielt relevante for store organisasjoner som bygger AI-losninger pa tvers av avdelinger. Microsoft Fabric stotter data mesh-arkitektur gjennom domener, OneLake shortcuts og foderert governance.
For norsk offentlig sektor, der departementer og direktorater har ulike datadomener med forskjellig regulering, er data mesh en naturlig tilnaerming. Direktoratet for digital tjenesteutvikling, NAV, Skatteetaten og andre etater kan eie sine egne dataprodukter mens de deler data gjennom en felles plattform. Fabric-domener muliggjor dette uten a duplisere data pa tvers av organisatoriske grenser.
AI-arbeidsbelastninger krever data fra mange domener: kundedata, transaksjonsdata, sensordata og referansedata. En data mesh-tilnaerming sikrer at hvert domene leverer kvalitetsdata som et produkt, med klare kontrakter og SLAer, noe som er kritisk for palitelige ML-modeller og AI-agenter.
Domain-Oriented Data Ownership
Fabric-domener som byggeklosser
Microsoft Fabric implementerer data mesh gjennom domener som logisk grupperer data etter forretningsomrade:
Organisasjon (Fabric Tenant)
+-- Domene: Veidata
| +-- Arbeidsomrade: Trafikkmalinger
| +-- Arbeidsomrade: Vegstandard
| +-- Arbeidsomrade: Vaerdata
+-- Domene: Okonomi
| +-- Arbeidsomrade: Budsjett
| +-- Arbeidsomrade: Regnskap
+-- Domene: HR
| +-- Arbeidsomrade: Kompetanse
| +-- Arbeidsomrade: Bemanning
+-- Domene: AI/ML
+-- Arbeidsomrade: Feature Store
+-- Arbeidsomrade: Modelltrening
Roller i domenestyring
| Rolle | Ansvar | Fabric-mapping |
|---|---|---|
| Fabric Admin | Oppretter domener, tildeler domeneadministratorer | Tenant-niva admin |
| Domain Admin | Styrer domenet, godkjenner tilgang, delegerer innstillinger | Forretningseier |
| Domain Contributor | Tilordner arbeidsomrader til domenet | Workspace admin |
| Data Producer | Bygger og vedlikeholder dataprodukter | Dataingeniorer |
| Data Consumer | Bruker dataprodukter fra andre domener | Analytikere, ML-ingeniorer |
Opprette domener i Fabric
Domener opprettes via admin-portalen eller REST API:
# Via Fabric REST API
import requests
headers = {
"Authorization": f"Bearer {access_token}",
"Content-Type": "application/json"
}
# Opprett domene
domain_payload = {
"displayName": "Veidata",
"description": "Alle dataprodukter relatert til veiinfrastruktur og trafikk"
}
response = requests.post(
"https://api.fabric.microsoft.com/v1/admin/domains",
headers=headers,
json=domain_payload
)
domain_id = response.json()["id"]
print(f"Domene opprettet: {domain_id}")
Subdomener for finmasket organisering
Domene: Veidata
+-- Subdomene: Trafikkstrom
| +-- Trafikktellepunkter (Lakehouse)
| +-- Reisetidsmaalinger (Lakehouse)
+-- Subdomene: Veistandard
| +-- Dekketilstand (Lakehouse)
| +-- Baerevne (Lakehouse)
+-- Subdomene: Hendelser
+-- Ulykker (Lakehouse)
+-- Vedlikehold (Lakehouse)
Data Product Versioning and Contracts
Data som produkt-prinsippet
Hvert dataprodukt bor oppfylle folgende krav:
| Krav | Beskrivelse | Implementering i Fabric |
|---|---|---|
| Oppdagbart | Lett a finne for konsumenter | OneLake Catalog med domenfiltrering |
| Adresserbart | Unik identifikator | Workspace/Lakehouse/Table-sti |
| Palitelig | SLA for tilgjengelighet og kvalitet | Pipeline-monitorering + DQ-regler |
| Selvbeskrivende | Dokumentert skjema og semantikk | Metadata, tags, endorsements |
| Interoperabelt | Standard format for deling | Delta Lake / Parquet via OneLake |
| Sikkert | Tilgangsstyring per domene | Workspace RBAC + OneLake Security |
Versjonering av dataprodukter
# Dataprodukt-versjonering via Delta Lake tidsreise
# Hver skriving til en Delta-tabell oppretter en ny versjon
# Lag en versjonert tabell med metadata
spark.sql("""
CREATE TABLE IF NOT EXISTS lakehouse.default.traffic_product_v2 (
measurement_id BIGINT,
station_id STRING,
timestamp TIMESTAMP,
vehicle_count INT,
avg_speed DOUBLE,
road_surface_temp DOUBLE,
-- Ny kolonne i v2
weather_condition STRING
)
USING DELTA
TBLPROPERTIES (
'delta.columnMapping.mode' = 'name',
'product.version' = '2.0',
'product.owner' = 'veidata-teamet',
'product.sla.freshness' = 'PT15M',
'product.sla.availability' = '99.5%'
)
""")
Datakontrakter
# data-contract.yaml - Kontrakt for trafikkdata-produktet
product:
name: traffic-measurements
version: "2.0"
owner: veidata-teamet
domain: veidata
subdomain: trafikkstrom
schema:
type: delta
location: onelake://workspace/lakehouse/Tables/traffic_measurements
columns:
- name: measurement_id
type: BIGINT
nullable: false
description: Unik ID for maalingen
- name: station_id
type: STRING
nullable: false
description: Tellepunkt-ID (NVDB-referanse)
- name: timestamp
type: TIMESTAMP
nullable: false
description: Maalingstidspunkt (UTC)
- name: vehicle_count
type: INT
nullable: false
description: Antall kjoretoy i perioden
quality:
freshness: PT15M # Maks 15 minutter gammelt
completeness: 99.0%
uniqueness:
columns: [measurement_id]
threshold: 100%
sla:
availability: 99.5%
response_time: P1D # Innen 1 dag for support
breaking_changes: 30d # 30 dagers varsel for breaking changes
Cross-Domain Data Sharing via Shortcuts
OneLake Shortcuts for Data Mesh
Shortcuts er den primaere mekanismen for datadeling mellom domener uten a kopiere data:
Domene A: Veidata Domene B: AI/ML
+---------------------------+ +---------------------------+
| Lakehouse: Trafikk | | Lakehouse: Feature Store |
| Tables/ | | Tables/ |
| traffic_measurements |------->| traffic_features (shortcut) |
| road_conditions |------->| road_features (shortcut) |
+---------------------------+ +---------------------------+
| |
| +---------------------------+
| | Lakehouse: Modelltrening |
+-------------------------->| raw_traffic (shortcut) |
+---------------------------+
Opprette cross-domain shortcuts
# Opprett shortcut fra AI/ML-domenet til Veidata-domenet
import requests
shortcut_payload = {
"name": "traffic_measurements",
"path": "Tables",
"target": {
"oneLake": {
"workspaceId": "veidata-workspace-id",
"itemId": "trafikk-lakehouse-id",
"path": "Tables/traffic_measurements"
}
}
}
response = requests.post(
f"https://api.fabric.microsoft.com/v1/workspaces/{ml_workspace_id}/items/{feature_store_id}/shortcuts",
headers=headers,
json=shortcut_payload
)
Cross-tenant datadeling
For deling mellom organisasjoner (f.eks. mellom Direktoratet for digital tjenesteutvikling og Meteorologisk institutt):
Tenant A: Direktoratet for digital tjenesteutvikling Tenant B: MET
+----------------------------+ +----------------------------+
| OneLake | | OneLake |
| Workspace: Vaerdata | | Workspace: Observasjoner |
| Tables/ | | Tables/ |
| weather_obs (shortcut) <------ weather_observations |
+----------------------------+ +----------------------------+
Krav for cross-tenant deling:
- Fabric admin ma aktivere External Data Sharing i begge tenants
- Dataeier sender invitasjon
- Mottaker aksepterer og oppretter shortcut
- Data forblir read-only for mottaker
Federated Governance and Shared Platform
Foderert governance-modell
| Styringsniva | Ansvar | Verktoy |
|---|---|---|
| Tenant-niva | Globale policies, sikkerhetskrav | Fabric Admin Portal |
| Domene-niva | Domene-spesifikke regler, sertifisering | Domain Settings, Delegated Settings |
| Workspace-niva | Tilgangsstyring, kapasitet | Workspace RBAC, Capacity assignment |
| Dataprodukt-niva | Kvalitet, kontrakter, metadata | DQ-regler, Endorsements |
Delegerte innstillinger per domene
Fabric lar tenant-administratorer delegere visse innstillinger til domeneniva:
# Eksempel: Sertifiseringsinnstillinger per domene
# Via Fabric Admin Portal > Domains > Domain Settings > Delegated Settings
# Hvert domene kan ha:
# - Egne sertifiseringsregler
# - Egne sensitivitetsetiketter (default label)
# - Egne godkjennere for dataprodukt-sertifisering
OneLake Catalog for oppdagbarhet
OneLake Catalog er det sentrale punktet for a oppdage dataprodukter pa tvers av domener:
| Funksjon | Beskrivelse |
|---|---|
| Explore-fane | Bla gjennom og filtrer dataprodukter |
| Domenefilter | Vis kun data fra et spesifikt domene |
| Endorsements | Sertifiserte/promoverte dataprodukter |
| Govern-fane | Innsikt i governance-status |
| Secure-fane | Enhetlig visning av sikkerhetsroller |
Governance-pipeline for dataprodukter
1. Data Producer lager dataprodukt i sitt domene
|
2. Kvalitetskontroll (automatiserte DQ-regler)
|
3. Metadata og dokumentasjon pafort
|
4. Domain Admin gjennomgar og sertifiserer
|
5. Dataprodukt publiseres i OneLake Catalog
|
6. Konsumenter oppdager via Catalog og oppretter shortcuts
Scaling to 50+ Domains with OneLake
Kapasitetsplanlegging
For store organisasjoner med mange domener:
| Antall domener | Kapasitetsmodell | Governance-tilnaerming |
|---|---|---|
| 1-10 | Delt kapasitet | Sentralisert |
| 10-25 | Kapasitet per avdeling | Delvis foderert |
| 25-50 | Kapasitet per domene | Fullt foderert |
| 50+ | Dedikert kapasitet per domene + delt | Hub-and-spoke |
Deployment-monstre
Monster 1: Ett arbeidsomrade per Medallion-lag per domene
Domene: Veidata
+-- Workspace: veidata-bronze (Inntak)
+-- Workspace: veidata-silver (Transformasjon)
+-- Workspace: veidata-gold (Servering)
Domene: Okonomi
+-- Workspace: okonomi-bronze
+-- Workspace: okonomi-silver
+-- Workspace: okonomi-gold
Monster 2: Data mesh med domene-spesifikke dataprodukter
Domene: Veidata
+-- Workspace: trafikk-produkt (Bronze -> Gold)
+-- Workspace: vegstandard-produkt (Bronze -> Gold)
+-- Workspace: vaer-produkt (Bronze -> Gold)
Automatisering med Default Domains
For skalering kan default domains automatisk tilordne nye arbeidsomrader:
# Sett opp default domain slik at nye arbeidsomrader
# automatisk tilordnes riktig domene basert pa hvem som oppretter dem
# Eksempel: Alle arbeidsomrader opprettet av veidata-teamet
# tilordnes automatisk til Veidata-domenet
Overvaking pa tvers av domener
# Power BI-rapport over alle domener
# Bruk Fabric REST API for a samle metadata
def get_domain_health_metrics():
"""Samle helsemetrikker for alle domener."""
domains = requests.get(
"https://api.fabric.microsoft.com/v1/admin/domains",
headers=headers
).json()
metrics = []
for domain in domains["domains"]:
workspaces = requests.get(
f"https://api.fabric.microsoft.com/v1/admin/domains/{domain['id']}/workspaces",
headers=headers
).json()
metrics.append({
"domain": domain["displayName"],
"workspace_count": len(workspaces["workspaces"]),
"last_updated": domain.get("modifiedDateTime")
})
return metrics
Anti-patterns og fallgruver
| Anti-pattern | Problem | Losning |
|---|---|---|
| Sentralisert data team | Flaskehals, lang leveransetid | Domene-eierskap med shared platform |
| Ingen datakontrakter | Breaking changes uten varsel | Eksplisitte kontrakter med SLAer |
| Data-kopiering mellom domener | Inkonsistens, hoy lagringskostnad | OneLake shortcuts |
| Alle domener pa en kapasitet | Stoyende naboer | Dedikert kapasitet per kritiske domener |
| Ingen sertifisering | Konsumenter vet ikke hva de kan stole pa | Endorsement-prosess |
| For mange smaa domener | Governance-overhead | Konsolider relaterte omrader |
Referanser
- Fabric domains -- Opprette og administrere domener i Fabric
- Best practices for planning and creating domains -- Planlegging av domenestruktur
- What is data mesh? -- Data mesh-konsepter i Cloud Adoption Framework
- Operationalize data mesh for AI/ML -- Data mesh for feature engineering
- OneLake shortcuts -- Cross-domain datadeling uten kopiering
- OneLake catalog overview -- Oppdagbarhet og governance
- Medallion lakehouse architecture -- Data mesh i Medallion-arkitektur
- Fabric deployment patterns -- Deployment-monstre for store organisasjoner
For Cosmo
- Bruk denne referansen naar kunder planlegger data mesh-arkitektur i Fabric, spesielt naar de har flere avdelinger/team som trenger a dele data for AI-formaal.
- Start med domener i Fabric som den primaere mekanismen -- ikke overkompliser med ekstern tooling. Fabric har innebygd stotte for domener, foderert governance og cross-domain shortcuts.
- OneLake shortcuts er nogkelen til data mesh i Fabric -- de eliminerer behovet for dataduplisering mellom domener og sikrer en enkelt kopi av sannheten.
- For norsk offentlig sektor: Koble domener til organisasjonens struktur (direktorat, seksjon, enhet). Bruk Utredningsinstruksen og samordningsplikten som argumenter for a dele data som produkter.
- Advar mot for tidlig skalering: Start med 3-5 domener for de viktigste datoomradene, la organisasjonen modnes, og utvid gradvis.