Salesforce Pek Çok Sistemden Biridir

🌐 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 1.‘i. Her modül kendi başına okunabilir. Sonraki: Kurumsal Veri Türleri

Bu modülün yanıtladığı soru: Bir veri mimarı neden org’u tasarlamadan önce onu neyin çevrelediğini çizer?

CTA adaylarına ders verdiğimde ilk günden sonraki ödev hep aynıdır. Senaryoyu okuyun. Sistem haritasına boş bir tuvalden başlayın. Ancak ondan sonra veri modeline bir deneme yapın. Nesneler değil, ayrıntılı entegrasyonlar değil: harita. Salesforce’un içine neyin ait olduğuna karar vermeden önce onu neyin çevrelediğini görmek isterim.

Bu, pek çok Salesforce profesyoneli için bir bakış açısı değişikliğidir. Kariyerinizi bir yönetici ya da geliştirici olarak geçirdiyseniz Salesforce doğal olarak dünyanızın merkezidir. Kurulum’u açarsınız, nesneler oluşturursunuz, flow’lar inşa edersiniz, Apex yazarsınız ve diğer sistemleri Salesforce’a doğru entegre edersiniz. Her şey org’la başlıyor gibi görünür. Bir mimar kamerayı geri çekmek zorundadır, çünkü bir kurumda Salesforce pek çok sistemden biridir ve çoğu zaman verinin sahibi olan sistem o değildir.

Önce Haritayı Çizin

2. bölüm mantıksal modeli kurdu, 3. bölüm de onun Salesforce’ta nasıl yaşadığını sordu. Şimdi sorunu büyüteceğim. Salesforce’un neye sahip olması gerektiğine karar vermeden önce etrafındaki kurumu anlamak istiyorum. Hangi sistemler zaten var? Müşteriler nerede oluşturuluyor, ürünler nerede tanımlanıyor, siparişler nerede başlıyor, faturalar nerede üretiliyor? Kimlik nerede yaşıyor? Analitik nerede yapılıyor, belgeler nerede tutuluyor, geçmiş nerede duruyor? Hangi sistemlerin Salesforce’un verisine ihtiyacı var ve Salesforce hangilerine bağımlı?

Bu sorular mimariyi değiştirir. Bu yüzden boş bir tuvalden başlar, Salesforce’u ortaya koyar ve etrafındaki her şeyi çizerim. 4. modül bunu tam olarak nasıl yerleştirdiğimi gösteriyor. Şimdilik ders basit: içinde yaşamak zorunda olduğu dünyayı anlamadan org’u tasarlamayın.

Salesforce Çoğu Zaman Kayıt Sistemi Değildir

Çok yaygın bir kurumu ele alın: Salesforce artı finansı, ürünleri, envanteri, satın almayı ve sipariş karşılamayı yürüten SAP ya da Oracle gibi bir ERP, yani kurumsal kaynak planlama sistemi. Şimdi basit bir soru sorun: müşteri nerede yaşıyor?

Salesforce olabilir, ERP olabilir ya da ikisi birden ve iş tam orada ilginçleşir. Satışçılar potansiyel müşterilerle Salesforce’ta Hesap olarak çalışabilir, ERP ise onlar ödeme yapan müşteri olduğunda resmî müşteri numarasını verir. Ürünler ve fiyatlar? Muhtemelen ERP. Envanter? Neredeyse hiçbir zaman Salesforce. Siparişler Salesforce’ta alınıp ERP’de karşılanabilir; faturalar ERP’den gelir; servis Salesforce’ta yaşar; analitik Salesforce raporları ile bir ambar arasında bölünmüştür. Birden güzel Salesforce veri modelimiz kurumsal veri modeli olmaktan çıkar. Onun bir parçasıdır.

Tekrar Tekrar Gördüğüm Entegrasyon

Gördüğüm en yaygın entegrasyon şöyledir: müşteriler, ürünler ve fiyatlar ERP’den Salesforce’a akar, siparişler dışarı akar. Yerine SAP, Oracle ya da başka herhangi bir ERP koyun; şekil aynıdır. Müşterinin ve ürünün altın kaydının sahibi ERP’dir, bu yüzden bu akışlar sağdan, Salesforce’a gelir. Satış, anlaşmayı Salesforce’ta kapatır; bu yüzden sipariş orada başlar ve karşılanmak, faturalanmak ve muhasebeleştirilmek için ERP’ye geri gider.

Bu akışlar yalnızca entegrasyon değildir. Bana kurumun gerçeğin nerede yaşadığına inandığını söylerler.

Tek Yönlü Oklar Beni Tedirgin Eder

Yalnızca tek bir akışı olan bir entegrasyon gördüğümde endişelenmeye başlarım. Üst düzeyde biri tek bir ok çizer: Salesforce’tan ERP’ye siparişler. Güzel. Şimdi daha derine bakın. ERP’nin müşterilerini, ürünlerini ya da fiyatlarını bilmiyorsam ERP’ye nasıl sipariş gönderebilirim? Sipariş, ERP’nin zaten sahip olduğu bir müşteriye bağlanmalıdır ve her satır, ERP’nin zaten sattığı bir SKU olmalıdır. Karşı tarafta var olmayan bir ürün için satır kalemi gönderemem. Dolayısıyla o sipariş oku çalışabilmeden önce, ters yönde ilerleyen geri akışların var olması gerekir.

Her oka sorduğum soru budur: bu akış neye bağlı? Gördüğünüz üst düzey ok, genellikle henüz çizmediğiniz geri akışlara ihtiyaç duyar.

Daha da derine bakın, dönüş yolculuğunu bulursunuz. Salesforce bir sipariş gönderir. Sonra ne olur? Kabul mü edildi, reddedildi mi? Gönderildi mi, kısmen mi gönderildi, iptal mi edildi? Faturalandı mı? Salesforce’ta birinin bunu bilmesi gerekiyor mu? Belki gerekmiyordur. Ama biri sormuş olmalıydı. Hiçbir şey geri gelmiyorsa sorun değil. Nedenini söyleyin.

Kurum Bir Anda Ortaya Çıkmadı

Haritaların karmaşıklaşmasının bir nedeni de kimsenin onları bir anda inşa etmemiş olmasıdır. Veri dalgalar halinde geldi. Önce dosyalar: sabit biçimli kayıtlar, sonra CSV gibi ayrılmış dosyalar. Sonra operasyonel veri için ilişkisel veritabanları. Sonra onu analiz için bir araya getiren veri ambarları. Sonra tablolara düzgünce oturmayan belgeler, anahtar-değer çiftleri ve grafikler için NoSQL veritabanları. Sonra çok büyük miktarda ham ve yarı yapılandırılmış veri için veri gölleri ve ikisini birleştiren lakehouse’lar. Kafka ya da Salesforce olay veri yolu gibi olay akışları, veriyi gece toplu işlerinde değil, olduğu anda taşır. Ve şimdi verinin başka bir platform kullanabilsin diye önce tek bir yere kopyalanması gerekmeyen federasyon.

Teknoloji henüz mesele değil. Mesele şu: yeni dalga eskisini nadiren ortadan kaldırır. Büyük bir kuruma girin, hepsini aynı anda bulursunuz: ilişkisel veritabanları, ERP, Salesforce, bir ambar, bir göl, SFTP aktarımları, API’ler, olay akışları, birinin hâlâ her Cuma e-postayla gönderdiği elektronik tablo ve onu inşa eden kişi altı yıl önce emekli olduğu için herkesin dokunmaktan korktuğu o tek sistem. Mimarisini yaptığınız kurum budur, ürün broşüründeki değil.

Farklı Sistemler Farklı Nedenlerle Var

“Tüm veriyi Salesforce’a nasıl getiririz?” ile hiç başlamamamın nedeni de bu. Neden hepsini orada isteyeyim? Salesforce, satış ve servis çalışanlarının müşterilerle çalışması için en iyi yer olabilir. Bu onu finans sistemi, kurumsal ambar, telemetri deposu, belge arşivi ya da şirketin ürettiği her tıklamanın, GPS okumasının ve tarihsel işlemin evi yapmaz.

3. bölüm tek bir org için bu veri nerede yaşamalı? diye sordu. Kurum düzeyinde aynı soru büyür: bazen veriye Salesforce sahiptir, bazen bir kopyasını tutar, bazen yalnızca bir referansı, bazen de ona hiç sahip olmamalıdır.

Çekirdek, Çekirdek Dışı ve Hyperforce

Anlaşılması gereken başka bir sınır var: “Salesforce” bile tek bir çalışma ortamı ve tek bir veritabanı değildir. 3. bölümde çekirdekte (on core), verinin nerede durduğu anlamına geliyordu: masanızın üstünde, org’un kendi nesnelerinde. Burada aynı sözcükler bir ürünün nerede çalıştığını anlatır. Mimarların ikisini de kullandığını duyacaksınız.

Tarihsel olarak Core çalışma ortamı platformun çoğunu barındırıyordu. Bugün Salesforce, Core’un uygulama meta verisi için tek kayıt sistemi olarak kaldığı, yüzlerce bağımsız, meta veri odaklı hizmetten oluşan bir platform tanımlıyor (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), İngilizce). Mimarların bir yeteneğin çekirdekte (on core) ya da çekirdek dışında (off core) çalıştığını söylediğini duymanızın nedeni bu.

Bu, platform hizmetlere bölünmeden çok önce de önemliydi. Bir sınıfa Salesforce’un teklif için neden Apttus’u değil de SteelBrick’i satın aldığını sorduğumda, aradığım yanıt basittir: SteelBrick %100 çekirdekte inşa edilmişti. Flow’lar ve tetikleyiciler çekirdekte yaşar; dolayısıyla orada inşa edilen bir ürün platformun meta verisini, özelleştirmelerini ve otomasyonunu da beraberinde alır. O teklif ürünü o zamandan beri yerini Revenue Cloud’a bıraktı, ama ders bırakmadı. Bir de çekirdeğe yakın (near-core) var ve kullandığım örnek Data 360. Data 360 çekirdek değildir. Kiracısı çekirdek dışındadır: veri ve onu işleyen mekanizmalar, org’un ilişkisel veritabanının içinde değil, yanında, kendi lakehouse’larında çalışır (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), İngilizce). Ama onu kurmak ve kontrol etmek için kullandığınız ekranlar çekirdekte, org’un içinde görüntülenir. Bu yüzden söyleyebileceğim en kesin ifade şu: çekirdekte yönetilir, çekirdek dışında barındırılır. Veri ya da işleme aslında Core’da çalışmaz; Core’daki arayüz, çekirdek dışındaki kiracıyı kontrol eder. Ve elbette bir de hiç Salesforce olmadığı için çekirdek dışında olan her şey var.

Bu yıl hangi ürünün nerede çalıştığını ezberlemeyi daha az önemserim, çünkü bu değişir; önemsediğim alışkanlıktır: bir sınır veri hareketini, gecikmeyi, kimliği, entegrasyonu ve veri yerelliğini etkileyebilir. Dolayısıyla bir ürün Salesforce diyor diye verisinin Hesap kayıtlarınızın hemen yanında durduğunu varsaymayın. Gerçek mimariye bakın.

Bir de Hyperforce var: Salesforce’un geleneksel kendi veri merkezleri yerine genel bulut için inşa edilmiş ve kod olarak tanımlanmış, müşterilere verilerinin nerede bulunacağı konusunda daha fazla seçenek sunan altyapısı (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), İngilizce). Bu önemlidir ve 5. modül ona geri dönüyor. Ama altyapı mimarisi kurumsal veri mimarisi değildir. Bir org’u genel buluta taşımak size müşterinin sahibinin kim olduğunu, envanterin nerede yaşadığını, analitiğin nerede çalıştığını ya da hangi verinin bir sınırı geçebileceğini söylemez. Hyperforce bu kararların bazılarını, özellikle veri yerelliğini şekillendirebilir. Haritayı bilmenin yerini tutmaz.

Harita Kutudan Önce Gelir

İşte alışkanlık. Biri size bir senaryo veriyor. Salesforce çözümünü inşa etmeye başlamayın. Önce sistemleri bulun: ERP, kimlik sağlayıcı, ambar, entegrasyon platformu, ortak sistemleri, müşteri kanalları, belge depoları. Sonra aralarında hareket eden veriyi bulun: müşteriler, ürünler, siparişler, faturalar, belgeler, olaylar, kimlikler. Sonra her birinin sahibini sorun. Ancak ondan sonra Salesforce’a neyin ait olduğuna karar verin. Yoksa neye bağlandığını bilmeden bir kutu tasarlıyorsunuz demektir.

Click to enlarge

Adım 1/3: tasarladığımız org, tek başına. Buradan bakınca bütün dünya gibi görünüyor.

Click to enlarge

Adım 2/3: uzaklaşın. Salesforce birçok sistemden yalnızca biri (bu düzeni 4. modül öğretiyor).

Click to enlarge

Adım 3/3: ilk oklar. Müşteriler, ürünler ve fiyatlar ERP’den gelir, siparişler gider: oklar, kuruluşun doğrunun nerede durduğuna inandığını söyler.

Harita Veri Modelini Değiştirir

Bunun bir veri mimarı için neden önemli olduğu da bu. 2. bölüm müşterinin önemli bir varlık olduğunu söyler. Tamam. Sonra harita müşteri için esas kaynağın ERP olduğunu söyler. Bu fiziksel modeli değiştirir. Salesforce, insanlar her gün kullandığı için yine de yerel bir Hesap tutabilir, ama artık ERP’nin tanımlayıcısına bir Harici Kimlik olarak ihtiyacımız var; Salesforce’un hangi alanları değiştirebileceğini bilmemiz gerekiyor (3. modülde göreceğimiz gibi ERP’nin alanlarını erp_ önekiyle işaretlerim); ERP değişikliklerinin ne hızla geldiğini; Salesforce’un ERP haberdar olmadan bir müşteri oluşturup oluşturamayacağını ve ikisi çeliştiğinde ne olacağını. Bunlar sonraya bırakılacak entegrasyon soruları değil. Veri mimarisi sorularıdır ve onları harita açığa çıkardı.

İşte bunlardan birinin nasıl ısırdığı. Bir satışçı büyük bir içecek şirketi için bir potansiyel müşteriyi dönüştürür, Hesabı oluşturur, anlaşmayı kazanır ve müşteri ERP’ye geçer. Ama şirket o içecek şirketiyle yıllardır iş yapıyordur ve ERP’de zaten vardır. Artık iki tane var. Satışçı o Hesabı hiç oluşturabilmeli miydi? 5. ve 6. bölümler buna geri dönüyor; harita, onun geldiğini gördüğünüz yerdir.

Mimarın Burada Karar Verdikleri

• Salesforce’u hangi sistemlerin çevrelediği ve her birinin hangi rolü oynadığı.
• Her önemli veri türünün sahibinin hangi sistem olduğu; Salesforce’un ne kadarını tutacağına karar vermeden önce.
• Salesforce’a ne aktığı, dışarı ne aktığı ve ne geri geldiği.
• Salesforce’un hangi veriye sahip olması, hangisini kopyalaması, başvurması, federasyonla erişmesi, arşivlemesi ya da hiç dokunmaması gerektiği.
• Salesforce markası taşıyan her şeyin tek bir yerde yaşadığını varsaymak yerine hangi platform ve altyapı sınırlarının önemli olduğu.

Geliştiricilikten mimarlığa geçiş çoğu zaman yeni bir özellik öğrenmek değildir. Salesforce’a bakmayı ne zaman bırakacağınızı öğrenmektir: kamerayı geri çekin, veriyi izleyin, gerçeğin sahibini bulun, sonra geri gelip Salesforce’un işinin ne olması gerektiğine karar verin.

Daha Fazlası

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.