Ana Veriyi Yönetmenin Dört Yolu

🌐 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 2.‘si. Her modül kendi başına okunabilir. Önceki: Her Öznitelik İçin Tek Doğruluk Kaynağı · Sonraki: Eşleştirme, Birleştirme ve Hayatta Kalma

Bu modülün yanıtladığı soru: Kuruluşlar ana veriyi nasıl yönetir ve hangi tarz uyar?

1. modül yetkinin öznitelik öznitelik atandığını söyledi. Şimdi: bu öznitelikler aynı anda birkaç sistemde yaşadığında ne yaparız? Müşteri bilgisi Salesforce’ta, ERP’de, faturalamada, destekte, belki Data 360’ta, belki bir ambarda; her birinin kendi sürümü var. Ana veri yönetiminin (MDM) çözmeye çalıştığı sorun budur ve MDM tek bir mimari değildir. Dört kalıp duyacaksınız: kayıt defteri (registry), konsolidasyon, birlikte var olma (coexistence) ve merkezî. Bunlar ürün ayarları değil. Tek bir soruya dört yanıttır: yönetim katmanının ne kadar yetkisi var?

Ürünle Değil, Sorunla Başlayın

İnsanlar MDM’i duyar ve bir MDM ürünü aramaya başlar. Ben sorunla başlardım. Yalnızca birkaç kaydın aynı müşteri olduğunu bilmemiz mi gerekiyor? Analitik için birleşik tek bir görünüme mi ihtiyacımız var? Hangi değerlerin esas olduğuna karar verip onları diğer sistemlere geri göndermemiz mi gerekiyor? Yoksa herkes için ana veriyi oluşturan tek bir merkezî sistem mi istiyoruz? Çok farklı gereksinimler, çok farklı mimariler.

Kayıt Defteri: Bana Kimin Kim Olduğunu Söyle

En hafif kalıp. Bir kayıt defteri kaynakların yerini almaz. ERP müşterisini, Salesforce hesabını, faturalama müşterisini tutar ve kayıt defteri bu kayıtların aynı varlığı temsil ettiğini çözer: Salesforce hesabı 001…, ERP müşterisi SAP-43821 ve faturalama müşterisi BILL-9127 tek bir müşteriye aittir. Kaynaklar oldukları yerde kalır ve üzerlerine yazılmaz. Artık “bu müşteri hakkında bildiğimiz her şeyi göster” sorusunun bir yanıtı var.

Ama kayıt defterinin neyi yanıtlamadığına dikkat edin. Salesforce 123 Main Street, ERP 125, faturalama “123 Main St., Suite 200” diyor. Kayıt defteri bunların birbirine ait olduğunu biliyor. Hangisinin değişmesi gerektiğine karar vermiyor. Bağlamak yönetmek değildir.

Deneyimime göre Salesforce projelerinde norm kayıt defteridir, ardından konsolidasyon ve birlikte var olma gelir; saf merkezî MDM nadirdir. Kayıt defteri yaygındır, çünkü müdahaleci değildir. Değer elde etmeden önce her operasyonel sistemi yeniden tasarlamazsınız. Salesforce yaptığını yapmaya devam eder, ERP de yaptığını yapmaya devam eder ve siz bir kimlik katmanı eklersiniz. Bu, her sisteme “artık müşteri verisini sen kontrol etmiyorsun; bu yeni merkezî sistem kontrol ediyor” demekten çok daha küçük bir değişikliktir.

Click to enlarge

Kayıt defteri şunu yanıtlar: hangi kayıtlar aynı varlığa ait?

Konsolidasyon: Veriyi Bir Araya Getirin

Konsolidasyon, veriyi birkaç kaynaktan alıp raporlama, analitik, segmentasyon ve müşteri zekâsı için merkezî bir temsilde birleştirir. Tanıdık örnek bir ambardır: Salesforce müşteriyi, ERP finansal verileri, faturalama ödemeleri gönderir ve iş birimi sonunda müşteriyi sistemler genelinde analiz edebilir. Kaynaklar hâlâ vardır ve hâlâ esas olabilir. Yön önemlidir: veri konsolide sisteme doğru akar ve bu sistem genellikle yönetilen değişiklikleri geri göndermez. Müşterinin operasyonel yetkilisi olmadan daha iyi bir resmi.

Kayıt defteri ile konsolidasyonu karıştırmak kolaydır. Fark neyin merkezîleştirildiğindedir: kayıt defteri kimliği merkezîleştirir (“bunlar birbirine ait”); konsolidasyon verinin daha fazlasını merkezîleştirir (“öznitelikleri kullanabilmek için bir araya getirin”). Hiçbiri “bu merkezî sistem artık ana kaynak ve her uygulama onun değerlerini kabul etmeli” demez.

Click to enlarge

Konsolidasyon, sahipliği kaynaklardan almadan veriyi bir araya getirir.

Birlikte Var Olma: Karar Verin ve Geri Gönderin

Birlikte var olmada yönetim katmanı gerçek yetki alır. Veri hâlâ birkaç operasyonel sistemde yaşar, ama MDM süreci yönetilen değere karar verir ve onu geri yayımlar. Salesforce’ta, ERP’de ve faturalamada her birinde farklı bir yasal ad var; MDM süreci yönetilen adı belirler ve üçüne de dağıtır. Sistemler birlikte var olur, ama yönetilen değerde birleşirler.

Bu çok daha güçlü bir MDM biçimidir. “Bunlar birbirine ait” demiyor; “bu öznitelik için kurumun kullandığı değer bu” diyor. Bu, eşleştirmeden fazlasını gerektirir: iş kuralları, sahiplik, hayatta kalma kuralları, iki yönlü entegrasyon, hata yönetimi ve yönetişim; çünkü birinin bir değerin neden kazandığına karar vermesi gerekir.

Click to enlarge

Birlikte var olma yalnızca kayıtları bağlamaz. Yönetilen değerlere karar verir ve onları geri gönderir.

Merkezî: Ana Kaynak Doğruyu Yaratır

En güçlü kalıp. Merkezî MDM’de yönetilen ana veri merkezî ana kaynakta oluşturulur, orada tutulur ve diğer herkese dağıtılır. Her sistem kendi müşterisini oluşturup MDM’in onları sonradan uzlaştırması yerine yönetilen müşteriyi ana kaynakta oluşturursunuz, sonra onu Salesforce’a, ERP’ye ve faturalamaya gönderirsiniz. Çok güçlü yönetişim ve çok önemli bir değişiklik: var olan süreçler kendi müşterilerini oluşturur, kullanıcıların kendi iş akışları vardır, entegrasyonlar yerel oluşturmayı varsayar ve iş birimleri müşterinin ne olduğu konusunda anlaşamayabilir bile. Gördüğüm Salesforce haritalarında nadir olmasının nedeni bu. Doğru olabilir. Bir araç kurmaktan çok daha büyük bir karardır.

Click to enlarge

Merkezî MDM oluşturmayı ve yetkiyi ana kaynağa taşır.

Dördü Yan Yana

Tarz	Merkezîleştirilen	Kaynaklar kalıyor mu?	Yönetilen değerleri geri gönderiyor mu?
Kayıt defteri	Kimlik ve bağlantılar	Evet	Genellikle hayır
Konsolidasyon	Kimlik artı birleştirilmiş veri	Evet	Genellikle hayır
Birlikte var olma	Kimlik, veri ve yönetilen kararlar	Evet	Evet
Merkezî	Oluşturma ve yetki	Evet, tüketici olarak	Evet

Tabloda aşağı indikçe yönetim katmanı daha fazla yetki alır ve kuruluşun genellikle daha fazla değişmesi gerekir.

Sınav bilgisi. Dört MDM uygulama tarzını bilin: kayıt defteri (kimlikleri bağlar; kaynaklar verilerini tutar), konsolidasyon (veriyi genellikle analiz için bir araya getirir), birlikte var olma (yönetilen değerlere karar verir ve onları kaynaklara geri yayımlar) ve merkezî (ana kaynak veriyi oluşturur; kaynaklar onu tüketir).

Dolayısıyla “merkezî en olgun olanıdır, o halde herkes oraya ulaşmalı” diye bir şey yoktur. Sorunu çözen en hafif kalıbı seçin. Kayıtların birbirine ait olduğunu bilmeniz mi gerekiyor? Kayıt defterini düşünün. Analitik için birleşik bir görünüm mü? Konsolidasyon. Birkaç operasyonel sisteme geri eşitlenen yönetilen değerler mi? Birlikte var olma. Herkes için ana veriyi oluşturan ve kontrol eden tek bir süreç mi? Merkezî.

Data 360 Nereye Uyar?

Data 360 pek çok kaynak genelinde birleşik profiller oluşturur; bu kulağa MDM’e çok benzer gelir ve sorunun bir kısmını gerçekten çözer. Kimlik çözümlemesi kaynak profilleri birleşik bir kimlikte eşleştirir ve kaynak kayıtlara geri bağlantıları tutar (Data 360 Architecture (opens in a new tab), İngilizce). Bu onu en çok bir kayıt defterine yaklaştırır. Birleşik profilde uzlaştırılmış değerler de gösterebilir. Ama bu onu kaynakları yeniden yazan merkezî bir altın kayıt sistemi yapmaz. Birleşik bir görünüm otomatik olarak yönetilen bir kurumsal kayıt değildir. 4. modül tamamen bu farkla ilgili.

Ortak Bir Model Ortak Bir Doğru Değildir

Kanonik veri modeli terimini de duyacaksınız. Salesforce’un Hesap’ı, ERP’nin iş ortağı ve faturalamanın müşterisi, üzerinde anlaşılmış tanımlayıcıları ve öznitelikleriyle tek bir kurumsal kavrama, Müşteri’ye eşlenir; böylece her entegrasyonun diğer her sistemin şeklini anlaması gerekmez. Data 360’ın veri modeli, kaynakları ortak kavramlarda uyumlu hale getirmenin bir örneğidir. Ama kanonik bir model bunu nasıl tutarlı biçimde temsil ederiz? sorusunu yanıtlar. MDM bunu sistemler genelinde nasıl tanımlar, yönetir ve ana kaydını tutarız? sorusunu yanıtlar. Üç sistemi de kusursuz biçimde tek bir Müşteri şekline eşleyin, Salesforce yine 123 Main Street, ERP de 125 der. Yapıyı çözdünüz, yetkiyi değil. Uyumlaştırmak ve yönetmek birbirinin yerine kullanılamaz.

Tek Bir İş, Birkaç Kalıp

Dolayısıyla “Steve Trucking’in MDM’e ihtiyacı var” bir gereksinim değildir. Ne için? Perakende Ortakları, dağıtım merkezleri, ekipler, kamyonlar, Alıcılar farklı yetkileri olan farklı alanlardır: Perakende Ortakları Salesforce’ta ve finans ERP’sinde yönetilir, kamyon kimliği FleetLink’ten gelir, her Alıcı her teslimat için bir ortak tarafından sağlanır. Farklı alanlar farklı kalıplar alabilir ve bir alan içinde özniteliklerin farklı yetkileri olabilir. Bu yüzden diyagramın ortasına MDM etiketli bir kutu çizip çözüldü demeyin. Kutunun ne yaptığını sorun.

Tarz entegrasyonu da değiştirir. Kayıt defteri kimlik bağlantılarına; konsolidasyon güvenilir gelen akışlara; birlikte var olma her iki yönde veriye; merkezî ise ana kaynaktan dağıtıma artı diğer sistemlerin rakip bir doğru yaratmasını engelleyen kontrollere ihtiyaç duyar. Yetki büyüdükçe koordinasyon da büyür, hata yönetimi de: MDM yasal adı değiştirir ve ERP bunu reddederse ne olur? Birlikte var olmanın ve merkezînin “daha fazla özellikli kayıt defteri” olmamasının nedeni bu. Farklı operasyonel sorumluluklar taşırlar.

MDM Bir İş Kararıdır

En önemli nokta: MDM temelde bir teknoloji kararı değildir. Yetki hakkında bir karardır. Müşteriyi kim oluşturur, onu kim değiştirebilir, hangi değerin kazanacağına kim karar verir, hangi sistemler onu kabul etmelidir, çeliştiklerinde ne olur. Bir araç bu kararları uygulayabilir; kuruluşun onlar üzerinde anlaşmasını sağlayamaz. Bir MDM projesinin mükemmel bir teknolojiye sahip olup yine de başarısız olabilmesinin nedeni bu: teknik ekip eşleştirmeyi çözdü, iş birimi sahipliği hiç çözmedi.

Zor yoldan öğrendiğim genel ders şu: birkaç sistem aynı verinin ana kaydını tuttuğunda, Salesforce onların üzerinde anlaşmadığı şeyi uzlaştıramaz. Bir şirket iki ERP çalıştırdığında onları nasıl senkronize tuttuklarını sorarım. Onlar tutamıyorsa Salesforce da tutamaz. 5. modül bu hikâyeyi anlatıyor (Tek Müşteri, İki ERP).

Mimarın Burada Karar Verdikleri

• Sorunun kimlik bağlantılarına mı, birleştirilmiş veriye mi, geri gönderilen yönetilen değerlere mi yoksa merkezî oluşturmaya mı ihtiyaç duyduğu.
• Tüm kurum için tek bir kalıp yerine her veri alanına hangi kalıbın uyduğu.
• Yönetim katmanının ne kadar yetki aldığı ve hangi sistemlerin onun kararlarını kabul etmesi gerektiği.
• Uyumlaştırmayı yetkiyle karıştırmadan kanonik bir modele ihtiyaç olup olmadığı.
• Seçilen kalıbın entegrasyon yönünü, sahipliği ve hata yönetimini nasıl değiştirdiği.

Biri bir diyagrama bir MDM kutusu koyduğunda ne yaptığını sorun. Hangi kayıtların birbirine ait olduğunu biliyor mu? Verilerini birleştiriyor mu? Hangi değerlerin kazanacağına karar veriyor mu? Bu kararları geri gönderiyor mu? Veriyi en başta oluşturuyor mu? Yanıtlar size gerçekte hangi mimariye sahip olduğunuzu ve yetkinin nerede yaşadığını söyler.

Daha Fazlası

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