Gå til indhold
SteveTechArcSteveTechArc Courses

Ejerne fastsætter politikken, arkitekterne håndhæver den

Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kapitel 5 i Data Architect, del 1: At blive dataarkitekt. Forrige: Forstå virksomhedens data.

Sig »data governance«, og folk ser møder for sig: udvalg, politikker, et dokument, ingen læser. Jeg stiller et andet spørgsmål hver gang: hvor bliver politikken håndhævet?

Hvis politikken siger, at kun økonomi må ændre kundens juridiske navn, hvad forhindrer så alle andre i det? Hvis den siger, at teamene kun ser en modtagers adresse for deres egne stop og kun på dagen, hvad gør det så sandt? Hvis den siger, at noget skal gemmes i syv år, hvad fjerner det så efter syv? En politik uden et håndhævelsespunkt er for det meste et ønske. Min holdning er enkel: ejerne fastsætter politikken; arkitekterne håndhæver den. Dataejeren beslutter. Systemet, som arkitekten designer, gør det mekanisk sandt.

Og forvent ikke at blive færdig. Styring bliver aldrig færdig. Den går i bølger, op og ned, og holder det værste af de dårlige data ude. Den er enkel, når Salesforce står alene, og sværere, og mere nødvendig, når Salesforce er ét knudepunkt i det landskab, vi tegnede i kapitel 4. Derfor kom det kapitel først: Landskabet fortæller dig, hvor langt styringen skal række.

En økonomidirektør forklarer datapolitikkerne, mens arkitekten sætter det, der håndhæver hver af dem, op på tavlen: validering, deling og opbevaring

Billedet er genereret med AI.

Holdningerne i dette kapitel

Sektion kaldt “Holdningerne i dette kapitel ”
  • Kør programmet, sådan som virksomheden fungerer: centraliseret, fødereret eller hybrid; arkitekten skal vide, hvem der godkender en politik.
  • Postens ejer er ikke dataejeren. Feltet Owner styrer tildeling og adgang; ansvaret for dataene ligger hos forretningen.
  • Om oprettelse er åben eller låst, afhænger af styringen omkring dataene. Åben er fint for de fleste små og mellemstore org’er; lås den, når konti er mastered i eller synkroniseret med et ERP; mellemvejen er en foreløbig posttype med kontrolleret konvertering til den styrede.
  • Hvis ERP’et er master for et felt, ændrer du det ikke, du beder om at ændre det. Golden record er en hybrid: ERP’ets masterfelter kommer ind, Salesforces egne felter går aldrig tilbage, og tovejsflows har brug for en kollisionsregel.
  • Klassificér de følsomme felter, ikke alle felter. Dokumentér bredt; klassificér bevidst; behold både forretningsmæssige og tekniske metadata.
  • Undervis i reglerne. Mange arkitekter har aldrig hørt om lovene uden for deres egen region, og de love former systemdesignet.
  • Brug den indbyggede samtykkemodel, hvor du kan, i stedet for at bygge den igen.
  • For retten til at blive glemt: Styr først, hvor personoplysningerne havner. Sletning er sjælden og svær; design, så personoplysninger lander få steder, og find så hver kopi: felthistorik, arkiver, analysekopierne, søgeindekser og agentsamtaler, før tiden løber ud.
  • Shield er svaret på vigtige regulatoriske krav som kryptering af lagrede data, med afvejninger, som du designer efter.
  • Field Audit Trail, når det er reguleret. Standard-felthistorik er udgangspunktet.
  • Sæt Event Monitoring op, før du har brug for det, og stream hændelserne til et lager som Splunk. Du må ikke løbe ind i et problem og så opdage, at du ikke opsamlede dem.

Den styrede datalivscyklus

Sektion kaldt “Den styrede datalivscyklus ”
Den styrede livscyklus for data Den styrede livscyklus for data i syv trin, hvert med sit spørgsmål og eksempler på mekanismer i Salesforce. Indsaml: er det godt nok til at blive lukket ind? Valideringsregler, dubletregler, påkrævede felter, en kvalitetsport; modul 2. Klassificér: hvor følsomt er det? Felterne til dataklassificering for følsomhed, compliance og ejer; modul 3. Beskyt: hvem må se og ændre det? Deling, tilladelser, feltadgang, Shield-kryptering og maskering af sandboxes; modul 6. Brug: er denne brug tilladt? Samtykkemodellen, formål med databrug og adgang for integration og agenter; modul 5. Bevar: hvor længe gemmer vi det? Opbevaringspolitikker, arkiver, big objects; modul 6. Slet: hvad sker der til sidst? Privacy Center, sletningsjob, afidentificering; modul 5. Revidér: kan vi bevise det? Felthistorik, Field Audit Trail og Event Monitoring sendt til en SIEM; modul 6. Nedenunder: værktøjerne understøtter politikken; de definerer den ikke. FASE SPØRGSMÅLET MEKANISMER I SALESFORCE, FOR EKSEMPEL UNDERVISES I 1 · Indsaml Er det godt nok til at blive lukket ind? Valideringsregler, dubletregler, påkrævede felter, en kvalitetsport Modul 2 2 · Klassificér Hvor følsomt er det? Felter til dataklassificering: følsomhed, compliance, ejer Modul 3 3 · Beskyt Hvem må se og ændre det? Deling, tilladelser, feltadgang, Shield-kryptering, maskering af sandboxes Modul 6 4 · Brug Er denne brug tilladt? Samtykkemodel, formål med databrug, adgang for integration og agenter Modul 5 5 · Bevar Hvor længe gemmer vi det? Opbevaringspolitikker, arkiver, big objects Modul 6 6 · Slet Hvad sker der til sidst? Privacy Center, sletningsjob, afidentificering Modul 5 7 · Revidér Kan vi bevise det? Felthistorik, Field Audit Trail, Event Monitoring til en SIEM Modul 6 Værktøjerne understøtter politikken; de definerer den ikke. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Syv spørgsmål gennem dataenes liv. Værktøjerne understøtter politikken; de definerer den ikke.

Vejen gennem dette kapitel

Sektion kaldt “Vejen gennem dette kapitel ”

Seks moduler, der hver især står på egne ben.

  1. Styring designes ind i org’en. Ejere, forvaltere og vogtere; centraliseret, fødereret eller hybrid; postens ejer kontra dataejeren; at gøre hver politik til et håndhævelsespunkt.
  2. Hold dårlige data ude. »Godt nok« som en forretningsdefinition; åben kontra låst oprettelse, den foreløbige post og en posttype til hvert flow; den hybride golden record og tovejsflows; en kvalitetsbeslutning ved hver datagrænse.
  3. Kend dine data: ordbog, oprindelse og klassifikation. Forretningsmæssige og tekniske metadata; hvad dataene betyder, hvor de kom fra, hvordan de skal behandles, og hvorfor klassifikation uden håndhævelse er pynt.
  4. Privatlivslove former designet. Lovene, du skal kunne genkende, hvad de har til fælles (rettigheder, overførsler, anmeldelse af brud, ansvarlighed), og spørgsmålene, der overlever dem; anonymiseret kontra pseudonymiseret; compliance er ikke et produkt.
  5. Samtykke og retten til at blive glemt. Samtykke som data, standardmodellen for samtykke, fristen på hver anmodning, og at designe sletning, før den første kommer.
  6. Beskyt, opbevar og bevis. Krypteringens afvejninger, sandboxes, opbevaring, felthistorik og Field Audit Trail og Event Monitoring sat op, før der er brug for det.

Når du er færdig, så test dig selv med kapitlets studieguide: en tjekliste til eksamen, vanerne ud over den, ordene du skal kende og et par spørgsmål.

Hvad en arkitekt beslutter her

Sektion kaldt “Hvad en arkitekt beslutter her ”
  • Hvem der ejer hvert vigtigt datadomæne, og hvad der håndhæver hver ejers politik.
  • Hvilke dårlige data der holdes ude, og hvad der fanges, sættes i karantæne og rettes senere.
  • Hvilke felter der er følsomme, og hvad den klassifikation ændrer.
  • Hvor personoplysninger havner, hvad de må bruges til, og hvordan de fjernes fra hver kopi.
  • Hvor længe data og deres historik opbevares, og hvilken dokumentation der findes til at bevise, hvad der skete.

Dette kapitel er arkitekturvejledning, ikke juridisk rådgivning. Jura- og compliance-teams beslutter, hvilke love der gælder, og hvad de kræver; arkitekten omsætter de krav til design.

Ud over eksamen: Styring har fået en ny forbruger, agenten. Klassifikationen afgør, hvad den må hente, samtykket afgør, hvad den må bruge dataene til, og dataoprindelse og revision skal række hele vejen ud til, hvad den sagde og gjorde. Hvert modul slutter med, hvad AI ændrer for sin del af livscyklussen.

Læs mere

Sektion kaldt “Læs mere ”

Næste: Masterdata og identitet