Gå til innholdet
SteveTechArcSteveTechArc Courses

Eierne setter policyen, arkitektene håndhever den

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)

Kapittel 5 av Data Architect, Del 1: Å bli dataarkitekt. Forrige: Forstå virksomhetens data.

Si «datastyring» (data governance), og folk ser for seg møter: komiteer, policyer, et dokument ingen leser. Jeg stiller et annet spørsmål hver gang: hvor håndheves policyen?

Hvis policyen sier at bare økonomi kan endre kundens juridiske navn, hva stopper alle andre? Hvis den sier at teamene bare ser en mottakers adresse for sine egne stopp, og bare den dagen, hva gjør det sant? Hvis den sier at dette skal oppbevares i sju år, hva fjerner det etter sju? En policy uten et håndhevingspunkt er stort sett et ønske. Mitt standpunkt er enkelt: eierne setter policyen; arkitektene håndhever den. Dataeieren bestemmer. Systemet arkitekten designer, gjør det mekanisk sant.

Og ikke regn med å bli ferdig. Styring blir aldri ferdig. Den går i bølger, flo og fjære, og holder de verste dårlige dataene ute. Den er enkel når Salesforce står alene, og vanskeligere, og mer nødvendig, når Salesforce er én node i landskapet vi tegnet i kapittel 4. Derfor kom det kapitlet først: landskapet forteller deg hvor langt styringen må nå.

En økonomidirektør forklarer datapolicyene mens arkitekten fester opp hva som håndhever hver av dem: validering, deling og oppbevaring

Bildet er generert med KI.

Standpunktene i dette kapitlet

Section titled “Standpunktene i dette kapitlet ”
  • Driv programmet slik selskapet fungerer: sentralisert, føderert eller hybrid; arkitekten må vite hvem som godkjenner en policy.
  • Postens eier er ikke dataeier. Owner-feltet styrer tildeling og tilgang; ansvaret for dataene ligger hos virksomheten.
  • Åpen eller låst oppretting avhenger av styringen rundt dataene. Åpen er greit for de fleste små og mellomstore orger; lås den når kontoer forvaltes i eller synkroniseres med et ERP; mellomveien er en foreløpig posttype med kontrollert konvertering til den styrte.
  • Hvis ERP-et er master for et felt, endrer du det ikke, du ber om å få endre det. Golden record er en hybrid: ERP-ets masterfelt kommer inn, Salesforces egne felt går aldri tilbake, og toveisflyter trenger en kollisjonsregel.
  • Klassifiser de sensitive feltene, ikke hvert felt. Dokumenter bredt; klassifiser bevisst; ta vare på både forretningsmetadata og teknisk metadata.
  • Lær bort regelverket. Mange arkitekter har aldri hørt om lovene utenfor sin egen region, og disse lovene former systemdesignet.
  • Bruk den innebygde samtykkemodellen der du kan, i stedet for å bygge den på nytt.
  • For retten til å bli glemt: kontroller først hvor personopplysningene havner. Sletting er sjelden og vanskelig; design slik at personopplysninger havner på få steder, og spor så opp hver kopi: felthistorikk, arkiver, analysekopiene, søkeindekser og agentsamtaler, før fristen går ut.
  • Shield er svaret på sentrale regulatoriske krav som kryptering av lagrede data, med avveininger du designer for.
  • Field Audit Trail når det er regulert. Standard felthistorikk er utgangspunktet.
  • Sett opp Event Monitoring før du trenger det, og strøm hendelsene inn i et lager som Splunk. Du vil ikke støte på et problem og så finne ut at du ikke fanget dem opp.

Den styrte livssyklusen for data

Section titled “Den styrte livssyklusen for data ”
Den styrte livssyklusen for data Den styrte livssyklusen for data i sju trinn, hvert med sitt spørsmål og eksempler på mekanismer i Salesforce. Fange: er det godt nok til å slippes inn? Valideringsregler, duplikatregler, obligatoriske felter, en kvalitetsport; modul 2. Klassifisere: hvor sensitivt er det? Feltene for dataklassifisering for sensitivitet, etterlevelse og eier; modul 3. Beskytte: hvem kan se og endre det? Deling, tillatelser, felttilgang, Shield-kryptering og maskering av sandboxer; modul 6. Bruke: er denne bruken tillatt? Samtykkemodellen, formål med databruk og tilgang for integrasjon og agenter; modul 5. Beholde: hvor lenge tar vi vare på det? Oppbevaringspolicyer, arkiver, big objects; modul 6. Slette: hva skjer til slutt? Privacy Center, slettejobber, avidentifisering; modul 5. Revidere: kan vi bevise det? Felthistorikk, Field Audit Trail og Event Monitoring sendt til en SIEM; modul 6. Under: verktøyene støtter policyen; de definerer den ikke. FASE SPØRSMÅLET MEKANISMER I SALESFORCE, FOR EKSEMPEL UNDERVISES I 1 · Fange Er det godt nok til å slippes inn? Valideringsregler, duplikatregler, obligatoriske felter, en kvalitetsport Modul 2 2 · Klassifisere Hvor sensitivt er det? Felter for dataklassifisering: sensitivitet, etterlevelse, eier Modul 3 3 · Beskytte Hvem kan se og endre det? Deling, tillatelser, felttilgang, Shield-kryptering, maskering av sandboxer Modul 6 4 · Bruke Er denne bruken tillatt? Samtykkemodell, formål med databruk, tilgang for integrasjon og agenter Modul 5 5 · Beholde Hvor lenge tar vi vare på det? Oppbevaringspolicyer, arkiver, big objects Modul 6 6 · Slette Hva skjer til slutt? Privacy Center, slettejobber, avidentifisering Modul 5 7 · Revidere Kan vi bevise det? Felthistorikk, Field Audit Trail, Event Monitoring til en SIEM Modul 6 Verktøyene støtter policyen; de definerer den ikke. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Sju spørsmål gjennom dataenes liv. Verktøyene støtter policyen; de definerer den ikke.

Veien gjennom dette kapitlet

Section titled “Veien gjennom dette kapitlet ”

Seks moduler, og hver av dem står på egne ben.

  1. Styring designes inn i orgen. Eiere, forvaltere og forvarere; sentralisert, føderert eller hybrid; postens eier kontra dataeier; å gjøre hver policy om til et håndhevingspunkt.
  2. Hold dårlige data ute. Godt nok som en forretningsdefinisjon; åpen kontra låst oppretting, den foreløpige posten og en posttype for hver flyt; den hybride golden record og toveisflyter; en kvalitetsbeslutning ved hver datagrense.
  3. Kjenn dataene dine: ordbok, opphav og klassifisering. Forretningsmetadata og teknisk metadata; hva dataene betyr, hvor de kom fra, hvordan de må behandles, og hvorfor klassifisering uten håndheving er pynt.
  4. Personvernlover former designet. Lovene du bør kjenne igjen, hva de har til felles (rettigheter, overføringer, varsling av brudd, ansvarlighet), og spørsmålene som varer lenger enn dem; anonymisert kontra pseudonymisert; etterlevelse er ikke et produkt.
  5. Samtykke og retten til å bli glemt. Samtykke som data, standardmodellen for samtykke, fristen på hver forespørsel, og å designe sletting før den første forespørselen kommer.
  6. Beskytt, oppbevar og bevis. Krypteringens avveininger, sandkasser, oppbevaring, felthistorikk og Field Audit Trail, og Event Monitoring satt opp før behovet oppstår.

Når du er ferdig, test deg selv med studieguiden for kapitlet: en sjekkliste til eksamen, vanene utover den, ordene du bør kunne, og noen spørsmål.

Hva en arkitekt bestemmer her

Section titled “Hva en arkitekt bestemmer her ”
  • Hvem som eier hvert viktig datadomene, og hva som håndhever policyen til hver eier.
  • Hvilke dårlige data som holdes ute, og hva som fanges opp, settes i karantene og rettes senere.
  • Hvilke felt som er sensitive, og hva den klassifiseringen endrer.
  • Hvor personopplysningene havner, hva de kan brukes til, og hvordan de fjernes fra hver kopi.
  • Hvor lenge data og historikken deres oppbevares, og hvilke bevis som finnes for å vise hva som skjedde.

Dette kapitlet er arkitekturveiledning, ikke juridisk rådgivning. Juridisk avdeling og compliance-teamene bestemmer hvilke lover som gjelder og hva de krever; arkitekten gjør disse kravene om til design.

Utover eksamen: styring har fått en ny konsument, agenten. Klassifisering bestemmer hva den kan hente, samtykke bestemmer hva den kan bruke dataene til, og opphav og revisjon må nå helt fram til hva den sa og gjorde. Hver modul slutter med hva KI endrer for sin del av livssyklusen.

Les mer

Section titled “Les mer ”

Neste: Masterdata og identitet