İçeriğe geç

Sahipler Politikayı Belirler, Mimarlar Uygular

28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Data Architect kursunun 5. bölümü, 1. Kısım: Veri Mimarı Olmak. Önceki: Kurumsal Veriyi Anlamak.

“Veri yönetişimi” deyin, insanların gözünün önüne toplantılar gelir: komiteler, politikalar, kimsenin okumadığı bir belge. Ben her seferinde farklı bir soru sorarım: politika nerede uygulanıyor?

Politika yasal müşteri adını yalnızca Finans’ın değiştirebileceğini söylüyorsa başka birini ne durduruyor? Ekiplerin bir Alıcının adresini yalnızca kendi durakları için, yalnızca o gün görebileceğini söylüyorsa bunu ne doğru kılıyor? Bunu yedi yıl saklayın diyorsa yedi yıldan sonra onu ne kaldırıyor? Uygulama noktası olmayan bir politika çoğunlukla bir dilektir. Pozisyonum basit: sahipler politikayı belirler; mimarlar uygular. Veri sahibi karar verir. Mimarın tasarladığı sistem onu mekanik olarak doğru kılar.

Ve bitirmeyi beklemeyin. Yönetişim hiçbir zaman bitmez. Gelgitlerle ilerler, kötü verinin en kötüsünü dışarıda tutar. Salesforce tek başına durduğunda basittir; 4. bölümde çizdiğimiz haritada Salesforce bir düğüm olduğunda ise daha zor ve daha gereklidir. O bölümün önce gelmesinin nedeni bu: harita, yönetişimin ne kadar uzağa ulaşması gerektiğini size söyler.

Bir finans direktörü veri politikalarını açıklarken mimar her birini uygulayan şeyi iğneliyor: doğrulama, paylaşım ve saklama

Görsel yapay zekâ ile üretilmiştir.

  • Programı şirketin çalıştığı şekilde yürütün: merkezî, federe ya da karma; mimarın bir politikayı kimin onayladığını bilmesi gerekir.
  • Kayıt sahibi veri sahibi değildir. Sahip alanı atamayı ve erişimi belirler; verinin hesap verebilirliği iş birimindedir.
  • Kayıt oluşturmanın açık mı kilitli mi olacağı verinin etrafındaki yönetişime bağlıdır. Küçük ve orta ölçekli org’ların çoğu için açık olması sorun değildir; hesapların ana kaydı bir ERP’deyse ya da onunla eşitleniyorsa kilitleyin; orta yol, yönetilen kayıt türüne kontrollü dönüşümü olan geçici bir kayıt türüdür.
  • Bir alanın ana kaynağı ERP ise onu değiştirmiyorsunuz, değiştirilmesini istiyorsunuz. Altın kayıt karmadır: ERP’nin ana veri alanları içeri gelir, Salesforce’un kendi alanları asla geri gitmez ve çift yönlü akışların bir çakışma kuralına ihtiyacı vardır.
  • Her alanı değil, hassas alanları sınıflandırın. Geniş belgeleyin; bilinçli sınıflandırın; hem iş hem teknik meta veriyi tutun.
  • Düzenlemeleri öğretin. Pek çok mimar kendi bölgesi dışındaki yasaları hiç duymamıştır ve bu yasalar sistem tasarımını şekillendirir.
  • Mümkün olan her yerde hazır onay modelini kullanın; onu yeniden inşa etmeyin.
  • Unutulma hakkı için önce kişisel verinin nereye gittiğini kontrol edin. Silme nadirdir ve zordur; kişisel veri az sayıda yere düşecek şekilde tasarlayın, sonra süre dolmadan her kopyanın peşine düşün: alan geçmişi, arşivler, analitik kopyalar, arama dizinleri ve ajan konuşmaları.
  • Shield, bekleyen verinin şifrelenmesi gibi temel düzenleyici gereksinimlerin yanıtıdır; tasarımda hesaba katmanız gereken ödünleşimleriyle.
  • Düzenlemeye tabiyseniz Field Audit Trail. Varsayılan standart alan geçmişidir.
  • Event Monitoring’i ihtiyaç duymadan önce kurun ve olayları Splunk gibi bir depoya akıtın. Bir sorunla karşılaşıp sonra onları kaydetmediğinizi öğrenmezsiniz.
Yönetilen veri yaşam döngüsü Yedi aşamada yönetilen veri yaşam döngüsü, her biri kendi sorusu ve örnek Salesforce mekanizmalarıyla. Yakalama: içeri almaya yetecek kadar iyi mi? Doğrulama kuralları, yinelenen kayıt kuralları, zorunlu alanlar, bir kalite kapısı; 2. modül. Sınıflandırma: ne kadar hassas? Hassasiyet, uyumluluk ve sahip için veri sınıflandırma alanları; 3. modül. Koruma: onu kim görebilir ve değiştirebilir? Paylaşım, izinler, alan erişimi, Shield şifrelemesi ve sandbox maskeleme; 6. modül. Kullanma: bu kullanıma izin var mı? Onay modeli, veri kullanım amacı ve entegrasyon ile ajan erişimi; 5. modül. Saklama: onu ne kadar süre tutuyoruz? Saklama politikaları, arşivler, büyük nesneler; 6. modül. Silme: sonunda ne olur? Privacy Center, silme işleri, kimliksizleştirme; 5. modül. Denetim: kanıtlayabilir miyiz? Alan geçmişi, Field Audit Trail ve bir SIEM'e gönderilen Event Monitoring; 6. modül. Altta: araçlar politikayı destekler; onu tanımlamaz. AŞAMA SORU SALESFORCE MEKANIZMALARI, ÖRNEĞIN İŞLENDIĞI YER 1 · Yakalama İçeri almaya yetecek kadar iyi mi? Doğrulama kuralları, yinelenen kayıt kuralları, zorunlu alanlar, bir kalite kapısı 2. modül 2 · Sınıflandırma Ne kadar hassas? Veri sınıflandırma alanları: hassasiyet, uyumluluk, sahip 3. modül 3 · Koruma Onu kim görebilir ve değiştirebilir? Paylaşım, izinler, alan erişimi, Shield şifrelemesi, sandbox maskeleme 6. modül 4 · Kullanma Bu kullanıma izin var mı? Onay modeli, veri kullanım amacı, entegrasyon ve ajan erişimi 5. modül 5 · Saklama Onu ne kadar süre tutuyoruz? Saklama politikaları, arşivler, büyük nesneler 6. modül 6 · Silme Sonunda ne olur? Privacy Center, silme işleri, kimliksizleştirme 5. modül 7 · Denetim Kanıtlayabilir miyiz? Alan geçmişi, Field Audit Trail, bir SIEM'e Event Monitoring 6. modül Araçlar politikayı destekler; onu tanımlamaz. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Verinin yaşamı boyunca yedi soru. Araçlar politikayı destekler; onu tanımlamaz.

Altı modül, her biri kendi başına okunabilir.

  1. Yönetişim Org’un İçine Tasarlanır. Sahipler, veri sorumluları ve muhafızlar; merkezî, federe ya da karma; kayıt sahibi ile veri sahibi; her politikayı bir uygulama noktasına dönüştürmek.
  2. Kötü Veriyi Dışarıda Tutmak. Bir iş tanımı olarak “yeterince iyi”; açık ile kilitli kayıt oluşturma, geçici kayıt ve her akış için bir kayıt türü; karma altın kayıt ve çift yönlü akışlar; her veri sınırında bir kalite kararı.
  3. Verinizi Tanıyın: Sözlük, Köken ve Sınıflandırma. İş ve teknik meta veri; ne anlama geldiği, nereden geldiği, nasıl ele alınması gerektiği ve uygulamasız sınıflandırmanın neden süs olduğu.
  4. Gizlilik Yasaları Tasarımı Şekillendirir. Tanınması gereken yasalar, ortak yönleri (haklar, aktarımlar, ihlal bildirimi, hesap verebilirlik) ve onlardan daha uzun yaşayan sorular; anonimleştirilmiş ile takma adlandırılmış; uyumluluk bir ürün değildir.
  5. Onay ve Unutulma Hakkı. Veri olarak onay, standart onay modeli, her talepteki süre ve ilk talep gelmeden silmeyi tasarlamak.
  6. Koruyun, Saklayın ve Kanıtlayın. Şifrelemenin ödünleşimleri, sandbox’lar, saklama, alan geçmişi ve Field Audit Trail ve ihtiyaçtan önce kurulan Event Monitoring.

Bitirdiğinizde kendinizi bölüm çalışma rehberiyle sınayın: sınav için bir kontrol listesi, onun ötesindeki alışkanlıklar, bilinmesi gereken terimler ve birkaç soru.

  • Her önemli veri alanının sahibinin kim olduğu ve her sahibin politikasını neyin uyguladığı.
  • Hangi kötü verinin dışarıda tutulduğu ve neyin yakalanıp karantinaya alındığı ve sonra düzeltildiği.
  • Hangi alanların hassas olduğu ve bu sınıflandırmanın neyi değiştirdiği.
  • Kişisel verinin nereye gittiği, ne için kullanılabileceği ve her kopyadan nasıl kaldırıldığı.
  • Verinin ve geçmişinin ne kadar süre saklandığı ve ne olduğunu kanıtlamak için hangi kanıtların var olduğu.

Bu bölüm hukuki tavsiye değil, mimari rehberliktir. Hangi yasaların geçerli olduğuna ve neyi gerektirdiklerine hukuk ve uyumluluk ekipleri karar verir; mimar bu gereksinimleri tasarıma dönüştürür.

Sınavın ötesinde: yönetişimin yeni bir tüketicisi var: ajan. Sınıflandırma neyi getirebileceğine, onay veriyi ne için kullanabileceğine karar verir; köken ve denetim de söylediği ve yaptığı şeye kadar uzanmalıdır. Her modül, yapay zekânın yaşam döngüsünün kendi kısmı için neyi değiştirdiğiyle biter.

Sonraki: Ana Veri ve Kimlik