Her Öznitelik İçin Tek Doğruluk Kaynağı

🌐 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)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 6. bölümü olan Ana Veri ve Kimlik bölümündeki 6 modülden 1.‘i. Her modül kendi başına okunabilir. Sonraki: Ana Veriyi Yönetmenin Dört Yolu

Bu modülün yanıtladığı soru: “Tek doğruluk kaynağı” gerçekte ne anlama gelir?

Sürekli duyduğum bir ifade var: “Tek bir doğruluk kaynağına ihtiyacımız var.” Tamam. Ne için? Müşteri için mi? Bu yeterince belirli değil. Bir hesabı alın. Müşterinin adının, fatura adresinin, kredi limitinin, hesap yöneticisinin, destek katmanının, pazarlama tercihlerinin sahibi kim? Bu yanıtlar aynı sistemi göstermez. Yasal adı, fatura adresini ve kredi durumunu ERP kontrol edebilir; ilişki sahibini ve satış özniteliklerini Salesforce; onayı başka bir platform. Bu yüzden biri bana “Salesforce müşteri için tek doğruluk kaynağımız” dediğinde bir sonraki sorum şudur: hangi doğru?

Doğruluk Bir Özniteliğe Aittir

Ana verinin ilk ilkesi şudur: yetki kayıt başına değil, öznitelik başına atanır. Bir hesap, Salesforce üzerindeki her alan için esas kaynak olmadan Salesforce’ta yaşayabilir. Tek bir kayıtta yedi alan, iki yetki:

Öznitelik	Esas sistem
Yasal ad, fatura adresi, ERP müşteri kimliği, kredi limiti	ERP
Hesap yöneticisi, stratejik hesap işareti, başarı katmanı	Salesforce

Tek kayıt; doğruluk dağıtılmış. Bu normaldir. “Kayıt sistemi = Salesforce” bunu tanımlamaz. Bir yetki modeli tanımlar.

Oluşturulan, Düzenlenen, Başvurulan; ve Ne Hızla?

Ana veriyi öğretirken her önemli veri parçası için aynı sorulara dönüp dururum: nerede oluşturuluyor, nerede düzenleniyor, nerede başvuruluyor ve değişim gecikmesi ne? Mimariyi hızla açığa çıkarırlar. (İlk üçüyle 4. bölümde, veri türlerini ayırırken tanıştınız; asıl işlerini burada görürler.)

Bir varlığı ele alın. Bir müşteri üç bisiklet sipariş ediyor. Fırsat ve satır kalemleri Salesforce’ta, sipariş ERP’ye gidiyor. ERP siparişi karşılıyor ve varlıklar orada oluşturuluyor: üç bisiklet, üç seri numarası, Salesforce’a geri gönderiliyor. Aylar sonra müşteri bunlardan biri için arıyor ve destek bir vakada varlığa başvuruyor. Şimdi birinin bir özniteliği düzeltmesi gerekiyor. Salesforce hangilerini düzenleyebilir, hangileri onları oluşturan ERP’ye aittir? Ve ERP birini değiştirdiğinde Salesforce’un bunu ne kadar hızlı bilmesi gerekir? Tek varlık, dört soru ve yanıtlar her alan için aynı değil.

Diyelim ki yasal ad ERP’de oluşturuluyor ve Salesforce’ta başvuruluyor ve bir temsilci onun yanlış olduğunu fark ediyor. Salesforce’ta düzeltmeli mi? Alanın sahibi ERP ise kopyayı değiştirmek hiçbir şeyi düzeltmez. En iyi ihtimalle bir sonraki eşitleme onun üzerine yazar; en kötü ihtimalle iki sistem artık çelişir ve kimse hangisine güveneceğini bilmez. İş birimi temsilcinin düzeltmeyi başlatmasını istiyorsa bu farklıdır: Salesforce deneyimi sağlar, ERP’ye bir talep gönderir, ERP değişikliği yapar ya da onaylar ve esas değer geri gelir. Bu, Salesforce’un alanı kendi başına düzenlemesine izin vermekten çok farklı bir mimaridir.

Gecikme de doğruluğun bir parçasıdır. ERP bir müşterinin kredi durumunu sabah 10.00’da değiştiriyor; Salesforce onu gecelik eşitliyor; saat 15.00’te bir temsilci Salesforce’a bakıyor. Değer yanlış mı? Bayat. Değer yılda bir değişiyorsa ve bir günlük gecikme hiçbir şeye mal olmuyorsa gecelik yeterlidir. Bugün bir milyon dolarlık siparişi kabul edip etmeyeceğinize karar veriyorsa değildir. Yetki doğruluğun nereden geldiğini; gecikme diğerlerinin değiştiğini ne hızla öğrenmesi gerektiğini söyler. İki ayrı karar.

Kayıt, Etkileşim, Referans Sistemi

4. bölümün sözcük dağarcığı burada yardımcı olur. Bir kayıt sistemi esas sürümü tutar. Bir etkileşim sistemi insanların onunla çalıştığı yerdir. Bir referans sistemi, başka bir sistemin kullandığı ama sahibi olmadığı veriyi sağlar. Salesforce müşteri ilişkisi için etkileşim sistemi olabilirken ERP yasal ve finansal öznitelikleri için kayıt sistemi olarak kalabilir. Bu mimaride bir zayıflık değildir; mimarinin kendisidir. Hata, diyagram daha basit görünsün diye tek bir sistemin her şeye sahip olması gerektiğini varsaymaktır.

Karma Altın Kayıt

Bu, “altın kayıt”ın anlamını değiştirir. 5. bölüm bu fikri kötü veriyi dışarıda tutarken tanıttı; burada tasarımın kalbidir. İnsanlar her alanının ana kaydı tek bir yerde tutulan büyülü bir kayıt hayal eder. Bazen tasarım budur. Salesforce’ta daha sık bir karma görürüm: hesabın bir kısmının ana kaydı başka bir yerdedir ve içeri kopyalanır (yasal ad, ERP müşteri numarası, fatura adresi, kredi durumu), bir kısmı da yalnızca Salesforce ona ihtiyaç duyduğu için vardır (hesap yöneticisi, fırsat stratejisi, başarı katmanı, ilişki notları). ERP alanları insanlar kullanabilsin diye içeri gelir. Salesforce alanları hiç geri gitmez, çünkü ERP onları umursamaz. Herkes hangisinin hangisi olduğunu bildiği sürece gayet makul.

Yetkiyi Görünür Kılın

Bu yüzden harici yetkiyi şemada apaçık hale getiririm. Bir alanı SAP kontrol ediyorsa bir önek alır: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Bu, 4. bölümün erp_ önekiyle aynı fikirdir. O yetki belirli ve sabitse sistemin adını, anlam bugünün tedarikçisinden daha önemliyse genel bir önek kullanın. Önemli olan, altı ay sonra modeli okuyan birinin şunu görebilmesidir: bu sadece bir Salesforce alanı daha değil; bu değerin sahibi başka bir sistem. İnsanları yetkiyi entegrasyonları tersine mühendislikle çözerek yeniden keşfetmeye zorlamayın.

Bir Yetki Haritası Oluşturun

Önemli ana veri için bir yetki haritası isterim: her temel öznitelik için onu kimin oluşturduğu, iş kararının sahibinin kim olduğu, hangi sistemin esas olduğu ve onu kimin ya da neyin değiştirebileceği. Dört farklı soru:

Öznitelik	Oluşturan	İş sahibi	Esas sistem	Değiştirebilen
Yasal ad	Finans	Finans	ERP	Finans süreci
Kredi limiti	Finans	Finans	ERP	Kredi ekibi
Hesap yöneticisi	Satış operasyonları	Satış	Salesforce	Satış yönetimi
Destek katmanı	Servis operasyonları	Servis	Salesforce	Servis yönetimi
Onay	Müşteri	Gizlilik	Onay platformu	Müşteri, onaylı bir süreç

İş sahibi ile esas sistemin aynı şey olmadığına dikkat edin. Bir sistem politikaya sahip olmaz; insanlar olur. Sistem sonucu saklar ve uygular. Bu yine 5. bölüm: sahipler politikayı belirler; mimarlar uygular.

Click to enlarge

Tek müşteri. Pek çok öznitelik. Her biri için tek yetki.

Yetki Yaşam Döngüsü Boyunca Değişir

Bir temsilci ERP’nin hiç duymadığı bir potansiyel müşteriyle tanışır ve hesabı Salesforce’ta oluşturur. O noktada ad, adres, kişiler ve değerlendirme için esas kaynak Salesforce’tur. Potansiyel müşteri müşteriye dönüşür; ERP resmî müşteriyi oluşturur ve müşteri numarasını, yasal adı, fatura adresini ve krediyi atar. Yetki taşındı. Salesforce daha önce yanlış değildi; yaşam döngüsü değişti. Bu, 5. bölümün geçiciden yönetilene kalıbıdır: dönüşümden önce potansiyel müşterinin sahibi Salesforce’tur; sonra yönetilen özniteliklerin sahibi ERP olur ve Salesforce kendi özniteliklerine sahip olmaya devam eder. Dolayısıyla “hesabın sahibi hangi sistem?” zayıf bir sorudur. Şunu sorun: yaşam döngüsünün bu noktasında bu özniteliğin sahibi hangi sistem?

Kopya Yetki Değildir

ERP verisini insanlar ona sürekli ihtiyaç duyduğu için Salesforce’a kopyalarız. Bu Salesforce’u kullanışlı bir yerel kopya yapar, ana kaynak değil; mimari de buna göre davranmalıdır: kullanıcılar için salt okunur, entegrasyon tarafından yenilenen, kaynağıyla etiketlenmiş, yalnızca bir talep aracılığıyla değiştirilen, kopya saptığında mutabakatla kontrol edilen. Kopya yararlıdır. Yetki yer değiştirmemiştir.

Güven Bir Değerden Fazlasını Gerektirir

“Fatura adresi: 123 Main Street.” Ona güvenmeli misiniz? Güven sinyalleri isterim: nereden geldiği, en son ne zaman teyit edildiği, onu hangi sistemin sağladığı ve onu en son kimin ya da neyin değiştirdiği: bir kişi mi, bir entegrasyon mu, bir ajan mı? Şimdi ERP 123 Main Street diyor, Salesforce 125 diyor ve bir ortak dosyası “123 Main St., Suite 200” diyor. Hangisi doğru? “En yenisini kullanın” diye yanıt vermeyin. Belki. Ama “en yeni” kendisi de onu en son değiştirenin kazanmayı hak ettiğini varsayan bir kuraldır. Bu doğru da olabilir, berbat da. 3. modül bunu ele alıyor. Güven, dolu bir alan bulmaktan değil, yetkiden ve kaynaktan gelir.

Steve Trucking: Bu Kimin Doğrusu?

Bir Perakende Ortağı bir teslimat gönderir ve o tek işlemde birkaç doğru saklıdır. Ortağın sipariş referansı ortağındır; Steve Trucking güncellemeleri eşleştirmek için onu tutar, ama onun ana kaynağı olmaz. Teslimat durumu (ulaştı, teslim edildi, kuruldu, bir istisna) Steve Trucking’indir; ortak onu alır, ama bir durumu almak ortağı kamyonda olanlar için esas kaynak yapmaz. Ve Alıcı ortağın müşterisidir. Ortak adı, adresi, telefonu ve teslimat notlarını Steve Trucking’in teslimat yapmak için onlara ihtiyacı olduğu için sağlar. Bu, Steve Trucking’i o kişinin kimliğinin ana kaynağı yapmaz ve bu ayrım kontrol noktasındaki Alıcı tasarımını belirler.

Click to enlarge

Tek teslimat, iki yetki.

Verinin nerede yaşadığı ile doğrusunun sahibinin kim olduğu farklı sorulardır. Salesforce ERP müşteri numarasını ona sahip olmadan tutabilir; Snowflake teslimat durumunu onun operasyonel ana kaynağı olmadan tutabilir; bir müşteri veri platformu her özniteliğe sahip olmadan kimlikleri birleştirebilir. Bir ajan üçünü de okuyabilir ve bu kesinlikle ajanın hangisinin doğru olduğuna karar vermesine izin vermez.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Ajanlar öznitelik yetkisini bir yürütme kuralına dönüştürür. Bir kişi yanlış bir fatura adresi görür ve “bu SAP’tan geliyor; burada değiştirmemeliyim” diye bilir. “Müşterinin fatura adresini güncelle” denen bir ajan, biz bunun için tasarım yapmadıkça bilmez. Mimarın sahip olduğu yetki haritasının aynısına ihtiyacı vardır: bir alana erişim, o alanı yazılacak doğru yer yapmaz.

Mimarın Burada Karar Verdikleri

• Bütün bir kayıt için tek bir sistem yerine, her önemli öznitelik için hangi sistemin esas olduğu.
• Her özniteliğin nerede oluşturulduğu, düzenlendiği ve başvurulduğu ve değişikliklerinin ne hızla iletilmesi gerektiği.
• Her özniteliğin politikasını kimin belirlediği ve hangi insanların, entegrasyonların ya da ajanların onu değiştirebileceği.
• Harici yetkinin modelde nasıl göründüğü: adlandırma önekleri, izinler, entegrasyon davranışı.
• Yetkinin yaşam döngüsü boyunca nasıl kaydığı; örneğin bir potansiyel müşterinin ERP’nin yönettiği bir müşteriye dönüşmesi.

Tek doğruluk kaynağı tek bir org, tek bir ERP, tek bir MDM platformu ya da dev tek bir kayıt demek değildir. Yönetilen her bilgi parçası için mimarinin esas değerin nerede olduğunu söyleyebilmesi ve diğer her sistemin buna göre nasıl davranacağını bilmesi demektir. Bu tek bir doğruluk kaynağı değildir. Bir doğruluk mimarisidir.

Daha Fazlası

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.