Styring designes inn i orgen
Finnes også på 28 språk
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 av 6 i kapitlet Datakvalitet og styring, kapittel 5 i kurset Data Architect. Hver modul står på egne ben. Neste: Hold dårlige data ute
Spørsmålet denne modulen besvarer: Hva betyr datastyring for en arkitekt, og hvem gjør hva?
Når folk hører datastyring (data governance), tenker de på møter: komiteer, policyer, standarder, et dokument som forklarer hvem som skal gjøre hva med dataene. Alt det kan være en del av et styringsprogram. Som arkitekt er jeg opptatt av et annet spørsmål: hvor håndheves policyen?
Hvis policyen sier at bare økonomi kan endre et felt, hva håndhever det? Hvis den sier at ERP-et eier den juridiske kundeposten, hva hindrer noen i Salesforce i å endre den? Hvis den sier at teamene bare ser en mottakers adresse for sine egne stopp, og bare den dagen, hva gjør det faktisk sant? Hvis den sier at dette skal oppbevares i sju år, hva arkiverer eller fjerner det etter sju? En policy uten et håndhevingspunkt er stort sett et ønske. Styring blir arkitektur når disse beslutningene bygges inn i systemet.
Styring blir aldri ferdig
Section titled “Styring blir aldri ferdig ”La meg få dette unnagjort tidlig: du blir aldri ferdig med styring. Jeg har sett det gå i bølger. Et selskap retter ordentlig oppmerksomhet mot datakvalitet, og ting blir bedre. Oppmerksomheten flytter seg et annet sted, og kvaliteten glipper. En ny integrasjon settes i drift, en forretningsenhet endrer prosessen sin, noen importerer en fil, selskapet kjøper opp et annet, en agent begynner å skrive poster, og problemet endrer seg igjen. Målet er ikke en mytisk tilstand der hver post er perfekt for alltid. Det er å holde dataene pålitelige nok for virksomheten og holde de verste dårlige dataene ute. Det er et kontinuerlig arbeid.
Når Salesforce stort sett står alene, betyr styring å rydde data på ett sted. Når det er én node i landskapet fra kapittel 4, blir det vanskeligere, og mer nødvendig. Nå bor kunden i Salesforce, ERP-et, datavarehuset, partnersystemer, Data 360. Hvem eier den? Hvem kan endre den? Hvilken kopi er autoritativ, hvilke attributter kan flyttes, hvor lenge oppbevares de, og hvem svarer når de er feil? Det er ikke konfigurasjonsspørsmål. Det er styringsspørsmål som blir konfigurasjon.
Postens eier er ikke dataeier
Section titled “Postens eier er ikke dataeier ”Start med ordet eier, for Salesforce gjør det forvirrende. Åpne en konto, og du ser en Owner: en selger, for eksempel. Eier selgeren kundedataene? Ikke nødvendigvis. I Salesforce eies en post på et objekt med eier av en bruker eller en kø; eieren får full tilgang, og eieren styrer tildeling og deling gjennom rollehierarkiet og delingsregler (Sharing and Record Access Features (opens in a new tab)). Det er posteierskap: en plattformmekanisme.
Dataeieren er noe annet: personen eller funksjonen som har ansvaret for dataene som en forretningsressurs. Økonomi kan eie den juridiske kundeinformasjonen, drift leveringsstatusen, HR de ansattes data. Salesforce gir deg til og med et sted å registrere det: klassifiseringsfeltet Data Owner på hvert felt (Data Classification Metadata Fields (opens in a new tab)).
Hos Steve Trucking kan kontoen til en detaljhandelspartner (Retail Partner) eies av salgslederen som har ansvaret for den partneren. Men partnerens juridiske identitet styres av økonomi og forvaltes som masterdata i økonomisystemet (ERP). Salg, service, drift og partnerportalen trenger alle kontoen; ingenting av det betyr at salgslederen skal endre partnerens juridiske identitet når økonomi først har fastsatt den. Jeg har sett team se på Owner-feltet og anta at de har løst dataeierskapet. Det har de ikke. Tildeling av poster er ikke forretningsansvar.
Eier, forvalter, forvarer
Section titled “Eier, forvalter, forvarer ”Tre styringsroller, tre forskjellige jobber.
Dataeieren setter policyen. Eieren svarer på hva dataene betyr, hvem som kan opprette og endre dem, hvor nøyaktige de må være, hvor lenge de oppbevares, hvem som kan se dem, hvilket system som er autoritativt, og hva som skjer når de er feil. Arkitekten skal ikke finne på de svarene. Det er et av mine fasteste standpunkter: eierne setter policyen; arkitektene håndhever den. Hvis økonomi sier at det juridiske navnet bare kan endres gjennom ERP-prosessen når kunden er aktiv, er det en styringsbeslutning. Å gjøre det mekanisk sant er min jobb.
Dataforvalteren (data steward) holder det i gang. Forvalteren er tett på den daglige helsen til dataene: følger med på kvalitetssignaler, undersøker duplikater, løser unntak, koordinerer rettinger, vedlikeholder definisjoner, oppdager prosessen som stadig produserer dårlige data. To jobber til ligger hos forvalteren. Når to team er uenige om hva et felt betyr, hvem som eier det eller hvem som kan se det, tar forvalteren tvisten til eieren og følger beslutningen helt i mål. Og forvalteren bygger datakompetanse (data literacy): hjelper menneskene som registrerer og bruker dataene, å forstå hva de betyr og hvorfor reglene finnes. En forvalter trenger mer enn et navn i et organisasjonskart. Forvalteren trenger tid, innsyn, en prosess og myndighet til å få problemene rettet. Ellers blir «dataforvalter» noens åttende ansvarsområde, som får et blikk én gang i kvartalet.
Forvareren (custodian) drifter systemet. Admins, plattformteam, sikkerhetsteam: de som drifter teknologien som lagrer og behandler dataene. Eieren sier at bare disse rollene kan se dataene; forvareren drifter kontrollene som sørger for det. Navnene betyr mindre enn at hvert ansvar er tydelig, og i en liten organisasjon kan én person ha to hatter.
Slik drives programmet
Section titled “Slik drives programmet ”Styringsprogrammer kommer gjerne i tre former. Sentralisert: ett team skriver policyene og standardene for alle domener. Det er konsistent, og det kan bli en flaskehals, langt unna dem som gjør jobben. Føderert (desentralisert): hvert domene, som økonomi, salg eller drift, styrer sine egne data innenfor noen få felles regler. Det er tett på arbeidet, og definisjonene glir fra hverandre mellom domenene. Hybrid: et lite sentralt team eier standardene og de felles definisjonene, og domeneeierne og forvalterne drifter sine egne data. De fleste virksomheter jeg har sett, ender et sted i hybriden. For arkitekten svarer formen på ett praktisk spørsmål: hvem godkjenner en policy før jeg håndhever den, og hvor bor de felles definisjonene?
Eksamenskunnskap. Kjenn de tre måtene å drive et styringsprogram på, sentralisert, føderert (desentralisert) og hybrid, og hva hver av dem betyr for hvem som setter policyen og hvor de felles definisjonene bor.
La RACI-en gjøre seg fortjent til plassen
Section titled “La RACI-en gjøre seg fortjent til plassen ”En RACI (hvem som er Responsible, Accountable, Consulted og Informed: utfører, har ansvaret, rådføres og informeres) hjelper, men ikke et gigantisk regneark laget fordi styring «krever et». Jeg vil at den skal svare på arkitekturspørsmål, og starte med de tre fra kapittel 4 (De fire spørsmålene bak kategoriene): hvor opprettes dataene, hvor redigeres de, og hvor refereres de? Det er ofte forskjellige systemer. Ta et produkt: ERP-et oppretter det, Salesforce refererer til det, portalen viser det, datavarehuset analyserer det. Nå endrer virksomheten hva «aktivt produkt» betyr. Hvor starter endringen, hvem godkjenner den, hvordan sprer den seg, og hvilke kopier er skrivebeskyttet? Hvis du ikke kan svare, har du ikke styring ennå. Du har kopier. En god RACI avslører nettopp den uklarheten.
Styring må bli mekanisk
Section titled “Styring må bli mekanisk ”Virksomheten sier at bare økonomi kan endre kundens juridiske navn. Jeg vil ikke at arkitektsvaret skal være «det tar vi i opplæringen». Opplæring hjelper; det er ikke håndheving. Kanskje er det tilgang på feltnivå, en valideringsregel, et felt som bare integrasjonen skriver til, eller en kontrollert prosess i stedet for direkte redigering. Mekanismen avhenger av kravet, men det må finnes en:
| Styringspolicy | Eieren bestemmer | Mulig håndhevingspunkt |
|---|---|---|
| ERP-et eier kundens juridiske identitet | Økonomi | Felt bare for integrasjonen, tillatelser, validering |
| Bare de som har behov, ser personopplysninger | Personvern, sikkerhet | Deling, tillatelser, felttilgang |
| Kundeidentifikatorer er unike | Forretningseier | Unik External ID, duplikatregler |
| Styrte poster opprettes ikke for hånd | Dataeier | Tillatelser, automatisering, integrasjon |
| Sensitive data har en fastsatt oppbevaringstid | Personvern, juridisk | En prosess for oppbevaring eller sletting |
| Viktige endringer må kunne bevises | Compliance | Felthistorikk, revisjonsspor |
| Kilden til dataene forblir identifiserbar | Dataeier | Et kildefelt, metadata om opphav |
Jeg skriver mulig håndhevingspunkt med vilje. Dette er ikke en tabell for å velge funksjoner. Det er rekkefølgen i tenkningen: hva er policyen, hvem eier den, og hva i arkitekturen gjør den sann?
Eierne setter policyen; arkitektene håndhever den.
Ikke stol på god oppførsel
Section titled “Ikke stol på god oppførsel ”«Endre aldri ERP-kunde-ID-en.» Alle vet det, helt til noen gjør det: ved et uhell, gjennom en datainnlasting, gjennom automatisering, gjennom en integrasjon, gjennom en agent. Hvis en endring ville skade virksomhetens data, er ikke «vær så snill, ikke gjør det» kontrollen. Bygg kontrollen. Stol på, men kontroller. Mennesker, integrasjoner, automatisering og KI gjør alle feil, så arkitekturen bør anta at noe før eller siden vil prøve det policyen forbyr. Hva skjer da?
Styring krysser systemgrenser
Section titled “Styring krysser systemgrenser ”Tilbake til landskapet. ERP-et eier kunden; Salesforce, datavarehuset og en kundedataplattform har kopier; en partner får noe av det. Hvilket system gjelder policyen for? Alle sammen. Salesforce kan med rette blokkere en endring av det juridiske navnet mens en integrasjon lar et system lenger ned i kjeden overskrive det. Salesforce kan slette personopplysninger som datavarehuset fortsatt har. Et felt klassifisert som sensitivt i Salesforce kan havne i et uklassifisert tekstfelt et annet sted. Styring kan ikke stoppe ved kanten av orgen, for det gjør ikke dataene. Derfor kom kapittel 4 først: landskapet forteller deg hvor langt styringen må nå.
Styr nok, ikke alt
Section titled “Styr nok, ikke alt ”Den motsatte feilen er like virkelig. Vi oppdager at styring betyr noe, så vi låser ned alt: ingen kan opprette, hver endring krever godkjenning. Dataene er styrt, og ingen får gjort jobben sin. Styring betyr den passende kontrollen for dataene: stram for noen, lett for andre. Noen poster kan opprettes fritt, noen krever godkjenning; noen felt kan nesten hvem som helst redigere, noen bare integrasjonen. Neste modul blir praktisk akkurat om det.
Og fordi styring aldri blir ferdig, trenger håndhevingen tilbakemelding. Øker antallet duplikater? Fylles obligatoriske felt opp med søppel? Feiler integrasjoner, finner brukerne omveier, vokser unntakene, bruker forvalterne hele dagen på ett problem? De signalene forteller deg om designet virker, og noen ganger at kontrollen, eller policyen, må endres.
Utover eksamen: hva KI endrer. Styring har fått en ny konsument: agenten. Dataeieren bestemmer fortsatt hva som kan brukes og til hva; arkitekten gjør det fortsatt håndhevbart. Det som endres, er fart og skala. En agent leser, kombinerer og handler på styrte data langt raskere enn et menneske, så en policy som bare finnes i et dokument, beskytter enda mindre.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hvem som har ansvaret for hvert viktig datadomene, og hvordan det skiller seg fra posteierskap.
- Hvem som forvalter dataene, og hvem som drifter dem som forvarer.
- Hvor viktige data opprettes, redigeres, refereres og forvaltes som masterdata på tvers av landskapet.
- Hvilket håndhevingspunkt som gjør hver viktig policy mekanisk sann.
- Hvordan arkitekturen viser om styringen virker, eller begynner å glippe.
Når jeg hører et styringskrav, oversetter jeg det. «ERP-et eier dette.» «Bare disse personene kan se dette.» «Vi må kunne bevise hvem som endret dette.» «Oppbevar dette i sju år.» Hver gang: vis meg håndhevingspunktet. Arkitekten bestemmer ikke policyen. Vi designer systemet som håndhever den. Det er der styring slutter å være et dokument og blir arkitektur.
Les mer
Section titled “Les mer ”- Salesforce Help, Sharing and Record Access Features (opens in a new tab), på engelsk, kontrollert 2026-10-14.
- Salesforce Help, Data Classification Metadata Fields (opens in a new tab), på engelsk, kontrollert 2026-10-14.