Salesforce'u Çevreleyen Sistemler

🌐 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 4. bölümü olan Kurumsal Veriyi Anlamak bölümündeki 6 modülden 3.‘sü. Her modül kendi başına okunabilir. Önceki: Kurumsal Veri Türleri · Sonraki: Sistem Haritasını Çizin

Bu modülün yanıtladığı soru: Salesforce’u ne çevreler ve her sistem hangi rolü oynar?

Önceki modül veriyi sınıflandırdı. Şimdi onu bir yere koymak istiyorum ve Salesforce mimarlarının başının derde girdiği yer burası. Salesforce’u biliyoruz; dolayısıyla müşteri verisi Hesap, sipariş verisi Sipariş, belgeler Dosyalar, analitik de Raporlar demektir. Ama kurum Salesforce’u sahip olduğu diğer her şeyin yerini alsın diye satın almadı. Finansı ve sipariş karşılamayı yürüten bir ERP, yıllarca geçmişi olan bir ambar, bir entegrasyon platformu, bir kimlik sağlayıcı, ortak sistemleri, bir olay platformu, bir MDM platformu ve bunların birkaçını birbirine bağlayan Data 360 olabilir. İş teknolojileri ezberlemek değildir. Her sistemin hangi işi olduğunu anlamaktır.

Ürün Adıyla Başlamayın

“SAP’imiz var” bana yeterince şey söylemez. Snowflake, MuleSoft, Tableau ya da Data 360 da söylemez. O sistemin bu mimaride ne yaptığını bilmek isterim: hangi verinin sahibi olduğunu, neyi okuduğunu, neyi değiştirdiğini, kimin kullandığını, neyin ona bağlı olduğunu, çöktüğünde ne olduğunu. İki şirket tamamen aynı ürünlere sahip olup bambaşka mimarilere sahip olabilir.

Bu yüzden sistemleri role göre etiketlerim. Dört rol çoğunu kapsar:

• Kayıt sistemi: bir şeyin esas sürümünün tutulduğu yer.
• Etkileşim sistemi: insanların işi yaptığı yer.
• Referans sistemi: bir sistemin ihtiyaç duyduğu ama sahibi olmadığı bilgi için gittiği yer.
• İçgörü sistemi: verinin ölçmek, analiz etmek ve tahmin etmek için bir araya geldiği yer.

Tek bir platform birkaç rol oynayabilir ve roller veriye göre değişir. Salesforce vakalar için kayıt sistemi, servis temsilcileri için etkileşim sistemi ve ERP’nin sahip olduğu ürün verisinin bir tüketicisi olabilir. Dolayısıyla biri “Salesforce bizim kayıt sistemimiz” dediğinde cümleyi tamamlayın: neyin kayıt sistemi?

ERP: Arka Ofisin Çekim Gücü Vardır

ERP, Salesforce’un yanında en sık karşılaşacağınız sistemdir; finansı, envanteri, satın almayı, sipariş karşılamayı ve faturalamayı yürütür. 1. modülün kalıbı (müşteriler ve ürünler içeri, siparişler dışarı), ürünlerin sahibinin ERP olduğu ama satışçıların onlara yine de Salesforce’ta ihtiyaç duyduğu anlamına gelir. Tamam: içeri getirin. Ama veriyi kopyalamak sahipliği devretmez. Bir kopya yetki değildir.

Pozisyonum: ERP’nin sahip olduğu veri yerel olarak okunur ve kontrollü biçimde yazılır. Salesforce kullanıcıları veriyi çalıştıkları yerde alır, ama Salesforce ERP’nin sahip olduğu şeyi değiştiremez. Ve bunu şemada görünür kılarım: ERP’nin alanları erp_Product_Number__c gibi bir erp_ öneki taşır; böylece nesneyi okuyan herkes her alanın sahibinin kim olduğunu ve onu değiştirirken dikkatli olması gerektiğini bilir. Önek hiçbir şeyi zorunlu kılmaz; bunu izinler, doğrulama ve entegrasyon kalıbı yapar. Niyeti iletir ve görünür kılınmış yetki haritasıdır.

Ambar, Göl ve Lakehouse

Operasyonel sistemler işi yürütür; analitik sistemler onu anlamaya yardım eder. “Bana açık fırsatlarımı göster” bir Salesforce raporudur. “Bana her kanalda beş yıllık satışları, sipariş karşılamayı, iadeleri, vakaları, envanteri ve finansı göster” farklı bir sorundur.

Üç tür analitik depoyla karşılaşacaksınız. Bir veri ambarı, analiz için hazırlanmış yapılandırılmış veriyi tutar. Bir veri gölü, çok daha fazla veriyi daha fazla biçimde, çoğu zaman ham olarak tutar. Bir lakehouse ikisini birleştirir: göl tarzı depolama ile ambar tarzı analiz. Onları tanıyın, çünkü haritalarda karşınıza çıkarlar. Ama deneyimim şu: lakehouse’lar ve data mesh, Salesforce projelerinde hâlâ niş. Tipik harita CRM, ERP, bir ambar ve bir entegrasyon katmanıdır; diğer platformlar işin gerçekten ihtiyaç duyduğu yerde yer alır. Mimariyi öğrenin; terimlerin peşinden koşmayın.

Analitik Verinin Yaşadığı Yerde Yaşar

Bu, en kesin pozisyonlarımdan biri: analitiğin yaşadığı yer verinin yaşadığı yeri izler. Rapor yalnızca hesaplara, fırsatlara ve satışçılara ihtiyaç duyuyorsa hepsi çekirdektedir: standart raporlar ve gösterge panoları. Sonra iş birimi ERP faturalarını eklemek ister. Sonra ürün maliyetini. Sonra ambardan beş yıllık siparişleri. Sonra web sitesi etkinliğini. Bir noktada, yalnızca raporlamak için bunların hepsini operasyonel CRM’e sürüklemek anlamsız hale gelir. Başka veri depoları devreye girdiğinde bir analitik platform gerekli hale gelir: Tableau (Data 360 üzerine kurulu Tableau Next dahil) ya da zaten kullanılıyorsa CRM Analytics. Salesforce verisi bir ambarla birleştirildiğinde vazgeçilmezdir. Gereksinim yalnızca daha karmaşık hale gelmedi; harita sorunun nerede yanıtlanması gerektiğini değiştirdi. Bu yüzden hiçbir zaman “hangi analitik aracı?” ile başlamam. Veri nerede? ile başlarım.

CTA adaylarına da aynı şeyi sorarım: “Diyagramlarımdan hangisi bunu harika çözüyor? Harita.” Her şey çekirdekteyse raporları kullanın. Başka depolarda veriniz varsa bir analitik platform görmek isterim. Harita, raporlama sorusunu daha kimse bir rapor oluşturucuyu açmadan yanıtlar. (Ürün adları değişir; Salesforce analitiğinin bugün nerede durduğunu Data 360 bölümü ele alıyor.)

MDM: Bu Müşteri Gerçekte Kim?

Şimdi müşteri bilgisinin Salesforce’ta, ERP’de, e-ticarette, bir sadakat platformunda ve bir ortak sisteminde yaşadığını ve her birinin müşterinin kim olduğunu bildiğini düşündüğünü varsayın. Ana veri yönetimi (MDM) burada devreye girer: temel verinin esas kimliğini sistemler arasında oluşturmak ve yönetmek. Ama MDM “bir ana müşteri veritabanı” değildir. Zor sorular şunlardır: müşteriyi hangi sistem oluşturabilir, hangi özniteliklerin sahibi hangi sistemdir, yinelenenler nasıl bulunur, hangi tanımlayıcı hayatta kalır ve sistemler çeliştiğinde ne olur. 6. bölüm tamamen bununla ilgili. Burada rolü tanıyın: bir MDM platformu varsa Salesforce ile kurumun geri kalanı arasında kritik bir yetki olabilir.

Entegrasyon Katmanı ve Olaylar

Her sistemi diğer her sisteme doğrudan bağlayın, harita hızla spagettiye döner. Kurumların bir entegrasyon katmanına sahip olmasının nedeni budur: bir ESB (kurumsal hizmet veri yolu) ya da iPaaS (hizmet olarak entegrasyon platformu). Salesforce haritalarında en çok karşılaşacağınız MuleSoft’tur. Aracılık eder; böylece her uygulamanın diğer her birini anlaması gerekmez.

Ama ortada bir MuleSoft kutusu olması entegrasyonu iyi yapmaz. Yine de neyin içinden geçip neyin geçmediğini, veriyi kimin dönüştürdüğünü, sözleşmenin sahibinin kim olduğunu, hedef çöktüğünde ne olduğunu, eşzamanlı mı eşzamansız mı olduğunu ve bir mesajın başarılı olduğunu nasıl bildiğimizi bilmek isterim. Integration Architect kursu derine iniyor; burada onu kendi başına bir rol olarak tanıyın.

Ve her entegrasyon A sisteminin B sistemini çağırması değildir. Bazen bir şey olur (bir sipariş oluşturulur, bir teslimatın durumu değişir, bir kamyon bir bölgeye girer), bir olay yayımlanır ve ilgilenen kim varsa yanıt verir. Hareket halindeki olayların da altyapısı vardır: Salesforce’un kendi olay yetenekleri, kurumsal bir olay veri yolu, diğer mesajlaşma sistemleri. Yalnızca veritabanlarını değil, veriyi taşıyan mekanizmaları da çizin.

Geliştiricilerin Unuttuğu Sistem: Kimlik

Haritada her zaman olmasını istediğim ve geliştiricilerin nadiren düşündüğü bir kutu var: kimlik sağlayıcı. Geliştiriciler sandbox’larına doğrudan bir kullanıcı adı ve parolayla girer; bu yüzden geliştirme sırasında kimlik görünmezdir. Sonra UAT ya da canlı ortam gelir ve birden çalışanlar için şirketin tek oturum açma sistemi, belki ortaklar için ikinci bir sağlayıcı, müşteriler için sosyal oturum açma ortaya çıkar. Kimlik her zaman mimarinin bir parçasıydı. Geliştirici yalnızca henüz görmemişti.

Bir kimlik sağlayıcı (IdP), bir kullanıcının kimliğini doğrulayan ve Salesforce’un güvendiği kimliği belirleyen sistemdir. Yayın hattında daha sonra yapılandırılsa bile ilk günden haritada yer alır, çünkü kimin içeri girebileceği, kimin veriye ulaşabileceğini belirler.

Pratik bir incelik de var: kimlik yapılandırması dağıtılabilir, ama tamamen değil. SAML tek oturum açma yapılandırması ve kimlik doğrulama sağlayıcıları Metadata API türleridir; dolayısıyla yayın hattında taşınırlar (SamlSsoConfig (opens in a new tab), İngilizce). Ama kimlik doğrulama sağlayıcılarının tüketici gizli anahtarları artık Metadata API yanıtlarında döndürülmüyor (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), İngilizce) ve sertifikalar genellikle ortama göre farklılık gösterir. Taşınan ve taşınmayan parçalar için plan yapın.

Click to enlarge

Haritayı logolar olarak değil, roller olarak okuyun: her sistem neyin sahibi, neyi okuyor, neye karar veriyor.

Data 360 Nerede Durur?

Data 360 güzel bir çizim sorusu doğurur. Onu sağa, ESB’nin veya MuleSoft’un altına koyarım. Nedeni bağlantılarıdır: kullanıcılar ona hiçbir zaman doğrudan bağlanmaz, o ise pek çok arka uç sisteme doğrudan bağlanır. Dolayısıyla kullanıcıların yanına değil, o hatların kısa kaldığı veri tesisatının yanına aittir. Onu insanların oturum açtığı başka bir ekran gibi çizerseniz yanlış hikâyeyi anlatıyorsunuz.

Yöneticiler ve veri ekipleri Data 360’ın ekranlarını açar, ama bu ekranlar org’un içinde, çekirdektedir. İşi yapan kiracı, yani verisi ve işlemesi, çekirdek dışında çalışır. Bu yüzden ona çekirdeğe yakın (near-core): çekirdekte yönetilir, çekirdek dışında barındırılır derim (terimleri 1. modül açıklıyor). Çizim kiracıyı izler: tesisatın yanında durur ve onu yöneten org’a geri giden tek bir hattı vardır.

Ne yaptığı, Salesforce’un sözleriyle, sıfır kopyayı (zero copy) içerir: bir kurumun veriyi kopyalamadan erişmesini ve sorgulamasını sağlayan bir veri federasyonu teknolojisi (Zero Copy (opens in a new tab), İngilizce). Yetenekler ve bağlayıcılar hızla değişiyor; bu yüzden onları bu modülü bir ürün turuna dönüştürmek yerine Data 360 bölümü gereği gibi ele alıyor.

Haritayı Sorumluluklar Olarak Okuyun

Bir haritaya baktığınızda logoları değil, sorumlulukları okuyun. ERP: neyin sahibi? Ambar: hangi soruları yanıtlıyor? Entegrasyon platformu: neyi taşıyor? IdP: kimin kimliğini doğruluyor? MDM: hangi kimliği yönetiyor? Data 360: neyi, ne için bağlıyor? Salesforce: gerçekte neyden sorumlu? Bunları yanıtlayabildiğinizde kutular bir anlam kazanır ve aralarındaki oklar çok daha ilginç hale gelir. Sırada onları bilinçli olarak çiziyoruz.

Mimarın Burada Karar Verdikleri

• Ürün adının ötesinde her sistemin hangi rolü oynadığı.
• Her önemli veri kümesi için hangi sistemin esas kaynak olduğu ve Salesforce’un nerede yalnızca yerel bir kopya tuttuğu.
• ERP’nin sahip olduğu verinin, yazma işlemleri kontrol altında olacak şekilde Salesforce’ta kullanılabilir olup olmadığı ve bu sahipliğin şemada nasıl göründüğü.
• Verinin yaşadığı yere göre analitiğin nereye ait olduğu.
• Kimliğin, entegrasyonun, olayların ve ana veri yetkisinin haritada nerede durduğu.

On dikdörtgenli bir harita mimari değildir; envanterdir. Mimari, her dikdörtgeni gösterip neden orada olduğunu, neyin sahibi olduğunu, kimin kullandığını, Salesforce’un ondan neye ihtiyaç duyduğunu ve rolünü yanlış anlarsanız neyin bozulacağını söyleyebildiğinizde başlar.

Daha Fazlası

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (ürün sayfası, İngilizce), kontrol tarihi 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (İngilizce).