Hoppa till innehåll

Ägarna sätter policyn, arkitekterna genomdriver den

Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kapitel 5 i Data Architect, Del 1: Att bli dataarkitekt. Föregående: Förstå företagets data.

Säg ”datastyrning” och folk ser möten framför sig: kommittéer, policyer, ett dokument som ingen läser. Jag ställer en annan fråga varje gång: var genomdrivs policyn?

Om policyn säger att bara Ekonomi får ändra kundens juridiska namn, vad hindrar alla andra? Om den säger att teamen bara ser en mottagares (Recipient) adress för sina egna stopp, och bara under dagen, vad gör det sant? Om den säger att detta ska sparas i sju år, vad tar bort det efter sju? En policy utan en punkt där den genomdrivs är mest en önskan. Min hållning är enkel: ägarna sätter policyn; arkitekterna genomdriver den. Dataägaren bestämmer. Systemet som arkitekten designar gör det mekaniskt sant.

Och räkna inte med att bli klar. Styrning blir aldrig klar. Den går i ebb och flod och håller ute det värsta av de dåliga data. Den är enkel när Salesforce står ensamt, och svårare, och mer nödvändig, när Salesforce är en nod i landskapet vi ritade i kapitel 4. Därför kom det kapitlet först: landskapet säger dig hur långt styrningen måste nå.

En ekonomichef förklarar datapolicyerna medan arkitekten fäster upp vad som genomdriver var och en: validering, delning och lagringstid

Bilden är genererad med AI.

  • Driv programmet så som företaget fungerar: centraliserat, federerat eller hybrid; arkitekten behöver veta vem som godkänner en policy.
  • Postens ägare är inte dataägaren. Fältet Owner styr tilldelning och åtkomst; ansvaret för data ligger hos verksamheten.
  • Öppet eller låst skapande beror på styrningen runt data. Öppet fungerar för de flesta små och medelstora orgar; lås det när konton hanteras som masterdata i eller synkas med ett ERP; mellanvägen är en provisorisk posttyp med kontrollerad konvertering till den styrda.
  • Om ERP:t är master för ett fält ändrar du det inte, du ber om att få ändra det. Golden record är en hybrid: ERP:ts masterfält kommer in, Salesforce egna fält går aldrig tillbaka, och dubbelriktade flöden behöver en kollisionsregel.
  • Klassificera de känsliga fälten, inte alla fält. Dokumentera brett; klassificera medvetet; behåll både affärsmetadata och teknisk metadata.
  • Lär ut regelverken. Många arkitekter har aldrig hört talas om lagarna utanför sin egen region, och de här lagarna formar systemdesignen.
  • Använd den färdiga samtyckesmodellen där du kan, i stället för att bygga om den.
  • För rätten att bli bortglömd: kontrollera först vart personuppgifterna tar vägen. Radering är ovanlig och svår; designa så att personuppgifter hamnar på få ställen, och leta sedan upp varje kopia: fälthistorik, arkiv, analyskopiorna, sökindex och agentkonversationer, innan tiden rinner ut.
  • Shield är svaret på viktiga regulatoriska krav som kryptering i vila, med avvägningar som du designar för.
  • Field Audit Trail när verksamheten är reglerad. Vanlig fälthistorik är standardvalet.
  • Sätt upp Event Monitoring innan du behöver det, och strömma händelserna till ett lager som Splunk. Du vill inte råka ut för ett problem och sedan upptäcka att du inte fångade dem.
Den styrda livscykeln för data Den styrda livscykeln för data i sju steg, vart och ett med sin fråga och exempel på mekanismer i Salesforce. Fånga: är det tillräckligt bra för att släppas in? Valideringsregler, dubblettregler, obligatoriska fält, en kvalitetsgrind; modul 2. Klassificera: hur känsligt är det? Fälten för dataklassificering för känslighet, regelefterlevnad och ägare; modul 3. Skydda: vem får se och ändra det? Delning, behörigheter, fältåtkomst, Shield-kryptering och maskning av sandboxar; modul 6. Använda: är den här användningen tillåten? Samtyckesmodellen, syfte med dataanvändning, och åtkomst för integration och agenter; modul 5. Behålla: hur länge sparar vi det? Lagringspolicyer, arkiv, big objects; modul 6. Radera: vad händer i slutet? Privacy Center, raderingsjobb, avidentifiering; modul 5. Granska: kan vi bevisa det? Fälthistorik, Field Audit Trail och Event Monitoring som skickas till en SIEM; modul 6. Under: verktygen stödjer policyn; de definierar den inte. FAS FRÅGAN MEKANISMER I SALESFORCE, TILL EXEMPEL LÄRS UT I 1 · Fånga Är det tillräckligt bra för att släppas in? Valideringsregler, dubblettregler, obligatoriska fält, en kvalitetsgrind Modul 2 2 · Klassificera Hur känsligt är det? Fält för dataklassificering: känslighet, regelefterlevnad, ägare Modul 3 3 · Skydda Vem får se och ändra det? Delning, behörigheter, fältåtkomst, Shield-kryptering, maskning av sandboxar Modul 6 4 · Använda Är den här användningen tillåten? Samtyckesmodell, syfte med dataanvändning, åtkomst för integration och agenter Modul 5 5 · Behålla Hur länge sparar vi det? Lagringspolicyer, arkiv, big objects Modul 6 6 · Radera Vad händer i slutet? Privacy Center, raderingsjobb, avidentifiering Modul 5 7 · Granska Kan vi bevisa det? Fälthistorik, Field Audit Trail, Event Monitoring till en SIEM Modul 6 Verktygen stödjer policyn; de definierar den inte. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Sju frågor genom datas livstid. Verktygen stöder policyn; de definierar den inte.

Sex moduler, som var och en står på egna ben.

  1. Styrning designas in i orgen. Ägare, förvaltare och förvarare; centraliserat, federerat eller hybrid; postens ägare kontra dataägaren; att göra varje policy till en punkt där den genomdrivs.
  2. Håll dåliga data ute. Tillräckligt bra som en affärsdefinition; öppet kontra låst skapande, den provisoriska posten och en posttyp för varje flöde; hybrid golden record och dubbelriktade flöden; ett kvalitetsbeslut vid varje datagräns.
  3. Känn dina data: ordlista, härkomst och klassificering. Affärsmetadata och teknisk metadata; vad data betyder, var de kommer ifrån, hur de måste hanteras, och varför klassificering utan genomdrivande är dekoration.
  4. Integritetslagar formar designen. Lagarna att känna igen, vad de har gemensamt (rättigheter, överföringar, anmälan av incidenter, ansvarsskyldighet), och frågorna som överlever dem; anonymiserat kontra pseudonymiserat; regelefterlevnad är ingen produkt.
  5. Samtycke och rätten att bli bortglömd. Samtycke som data, standardmodellen för samtycke, klockan som tickar för varje begäran, och att designa radering innan den första begäran kommer.
  6. Skydda, bevara och bevisa. Krypteringens avvägningar, sandboxar, lagringstid, fälthistorik och Field Audit Trail, och Event Monitoring som sätts upp innan behovet uppstår.

När du är klar kan du testa dig själv med kapitlets studieguide: en checklista inför provet, vanorna bortom det, orden att kunna och några frågor.

  • Vem som äger varje viktig datadomän, och vad som genomdriver varje ägares policy.
  • Vilka dåliga data som hålls ute, och vad som fångas upp, sätts i karantän och rättas senare.
  • Vilka fält som är känsliga, och vad den klassificeringen ändrar.
  • Vart personuppgifterna tar vägen, vad de får användas till och hur de tas bort från varje kopia.
  • Hur länge data och deras historik sparas, och vilka bevis som finns för att visa vad som hände.

Det här kapitlet är vägledning i arkitektur, inte juridisk rådgivning. Juridik- och compliance-teamen avgör vilka lagar som gäller och vad de kräver; arkitekten gör om de kraven till design.

Bortom provet: styrningen har en ny konsument, agenten. Klassificeringen avgör vad den får hämta, samtycket avgör vad den får använda data till, och härkomst och granskning måste nå ända fram till vad den sa och gjorde. Varje modul avslutas med vad AI ändrar för sin del av livscykeln.

Nästa: Masterdata och identitet