Araçlarınızı Tanıyın: Dokuz Soru

🌐 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 ilk bölümü olan Bir Veri Mimarı Gibi Düşünmek bölümündeki 7 modülden 6.‘sı. Her modül kendi başına okunabilir. Önceki: Bugün İçin İnşa Edin. Yarın İçin Planlayın. Başarısızlık İçin Planlayın. · Sonraki: Yapay Zekâ Çağında Veri Mimarı

Bu modülün yanıtladığı soru: Daha önce hiç görmediğiniz bir araç da dahil, herhangi bir aracı nasıl değerlendirirsiniz?

Mimarların muhakemeye ihtiyacı vardır. Ama bilgisiz muhakeme pek işe yaramaz. Yine de araçlarınızı tanımanız gerekir.

Yıllardır mimarlara ders veriyorum ve kullandığım çerçevelerden biri, mimarinizdeki her önemli araç ya da yetenek hakkında yanıtlayabilmeniz gereken bir dizi sorudur. Başlangıçta sekiz soru öğretiyordum. Bir dokuzuncusunu ekledim. Teknolojiler değişir, Salesforce değişir, yeni ürünler çıkar, eski yetenekler evrilir ve yapay zekâ bunların hepsini hızlandırıyor. Bu sorular işe yaramaya devam eder.

Dokuz Soru

Bir teknolojiyi öğrenirken ya da değerlendirirken şunları sorun:

1. Nedir?
2. Nerede kullanılır?
3. Nasıl kullanırım?
4. Alternatiflerim neler?
5. Güçlü yanları neler?
6. Zayıf yanları neler?
7. Onu geliştiricilere, iş birimine ve yöneticilere nasıl açıklarım?
8. Uzun vadede bakımı nasıl yapılır?
9. Maliyeti nedir, hangi lisansı gerektirir ve sınırları nelerdir?

Dokuzunu da yanıtlayabiliyorsanız aracı bir mimar gibi anlamaya başlıyorsunuz demektir. Listede olmayana dikkat edin: “Onu yapılandırabilir miyim?” Bu önemlidir, ama aracı tanımanın yalnızca bir parçasıdır.

Click to enlarge

1. Nedir?

Apaçık soruyla başlayın, çünkü insanlar onu şaşırtıcı sıklıkta atlar. Bir ürün ya da özellik adını duyarız ve hemen onu kullanıp kullanmamayı tartışmaya başlarız. Yavaşlayın. Gerçekte ne yapıyor? Hangi sorunu çözmek için tasarlandı? Mimaride nerede duruyor ve ne değil? Bir mimar, pazarlama açıklamasını tekrarlamadan bir teknolojiyi anlatabilmelidir. Bir şeyi birkaç cümleyle açıklayamıyorsam muhtemelen henüz yeterince iyi anlamamışımdır.

2. Nerede Kullanılır?

Bir şeyin ne yaptığını bilmek, ne zaman bir mimariye ait olduğunu bilmekle aynı şey değildir. Hangi tür sorunlarda iyidir? Hangi koşullar onu uygun kılar, hangi koşullar ondan şüphelenmeme neden olmalı? Bu, “bu özelliği biliyorum”dan “bu özelliğin çözdüğü sorunu tanıyorum”a geçiş adımıdır ve büyük bir adımdır. En sevdiğiniz teknolojiyi kullanacak yer arayarak dolaşmak istemezsiniz. Sorunları tanımak ve onlara hangi araçların uyduğunu bilmek istersiniz.

3. Nasıl Kullanırım?

Evet, mimarlar uygulamayı anlamalıdır. Her bileşeni inşa etmek zorunda değilsiniz, ama başkalarından ne inşa etmelerini istediğinizi bilecek kadar anlamalısınız. Nasıl yapılandırıldığını, bir geliştiricinin onunla nasıl çalıştığını, verinin içine ve dışına nasıl aktığını, nasıl dağıtıldığını ve güvence altına alındığını ve çalışırken neye benzediğini bilin. Bir mimarın yalnızca bir ürün sunumunda gördüğü bir teknolojinin etrafında tasarım yapmasını istemem. Elinizi taşın altına koyun: bir şey inşa edin, bir şeyi bozun, gerçekte nasıl davrandığını görün. Mimari gerçekliğe dayandığında daha iyi olur.

4. Alternatiflerim Neler?

Bu listedeki en önemli soru olabilir. Bir sorunu çözmenin tek bir yolunu biliyorsanız, elinizde mimari bir karar değil, bir varsayılan vardır. Biri bir teknoloji önerdiğinde başka ne yapabileceğimizi bilmek isterim. Başka bir Salesforce yeteneği mi? Bildirimsel bir şey mi, kod mu? Yetenek Salesforce’un dışında yaşayabilir mi? Veriyi kopyalamak yerine olduğu yerde bırakabilir miyiz, bir API çağrısı yerine bir olay kullanabilir miyiz ya da hiçbir şey inşa etmekten kaçınabilir miyiz? Alternatifler ödünleşimler yaratır ve ödünleşimler mimarinin kalbidir.

5. Güçlü Yanları Neler?

Her aracın bir varlık nedeni vardır. Gerçekte neyde iyi olduğunu anlayın: neyi kolaylaştırıyor, nerede iyi ölçekleniyor, hangi karmaşıklığı ortadan kaldırıyor, hangi sorunları zarif biçimde çözüyor. Teknolojileri güçlü yanlarının sorunla örtüştüğü yerlerde kullanın. Bu apaçık görünür, ama bir aracı zaten sahip olduğumuz için, ekip onu bildiği için, yeni olduğu için ya da biri bir demo gördüğü için seçmek çok kolaydır. Bunlar etken olabilir. Mimari uyumla aynı şey değildirler.

6. Zayıf Yanları Neler?

Bu da aynı derecede önemlidir. Her teknolojinin zayıf yanları vardır, istisnasız her birinin. Biri size bir teknolojinin yalnızca güçlü yanlarını söyleyebiliyorsa, henüz bir mimari tartışma yapmıyorsunuzdur. Neyi iyi yapmıyor? Karmaşıklık nerede ortaya çıkıyor ve ölçekte ne oluyor? Hangi operasyonel yükü ve bağımlılıkları getiriyor? Hangi gereksinimler onu ideal alanının dışına itiyor? Bir zayıflık, teknolojiyi kullanmamamız gerektiği anlamına gelmez her zaman. Neyi kabul ettiğimizi bilmemiz gerektiği anlamına gelir. Anladığınız bir ödünleşim mimari bir karar olabilir. Anlamadığınız bir ödünleşim bir sürprize dönüşebilir.

7. Onu Farklı Kitlelere Nasıl Açıklarım?

Bu, teknik bilgiyi mimari beceriden ayıran sorulardan biridir. Aynı teknolojiyi bir geliştiriciye, iş birimine ve bir yöneticiye açıklayabilir misiniz? Bunlar aynı açıklama olmamalıdır. Geliştiricinin API’lere, işlem davranışına, güvenliğe, hata yönetimine ve uygulama kalıplarına ihtiyacı vardır. İş birimi neyi mümkün kıldığını ve süreçlerinin nasıl değiştiğini önemser. Yönetici maliyeti, riski, zamanı, kurumsal etkiyi ve kararın hangi seçenekleri açık tuttuğunu ya da kapattığını önemser. Gerçeği değiştirmiyorsunuz; soyutlama düzeyini değiştiriyorsunuz. Bir teknolojiyi yalnızca belgelerinin sözcükleriyle açıklayabiliyorsanız, onu anlamak için çalışmaya devam edin.

8. Uzun Vadede Bakımı Nasıl Yapılır?

Projeler biter. Sistemler bitmez, en azından bitmemelerini umarız. Proje ekibi ayrıldıktan sonra birinin inşa ettiğimiz şeyin sahibi olması gerekir. Bu, nasıl izlendiğini, yükseltildiğini ve sorunlarının nasıl giderildiğini, onu desteklemek için kimin becerilere ihtiyaç duyduğunu, değişikliklerin nasıl dağıtılıp test edildiğini ve teknoloji evrildiğinde ya da Salesforce altımızda bir şeyi değiştirdiğinde ne olduğunu bilmek demektir. Üç yıl sonrasını hayal edin. Canlıya çıktığı gün çok zekice olan ve sonrasında işletmesi berbat olan mimariler gördüm. Bu başarı değildir. Bakım yapılabilirlik mimarinin bir parçasıdır.

9. Maliyeti Nedir, Hangi Lisansı Gerektirir ve Sınırları Nelerdir?

Bu, özgün sekiz soruya eklediğim sorudur ve bugün onu dışarıda bırakmanın imkânsız olduğunu düşünüyorum. Bir teknoloji mükemmel teknik çözüm olup ekonomisi tutmuyorsa yine de yanlış mimari çözüm olabilir. Sahip olduğumuz lisanslara dahil mi, yoksa bir eklenti mi? Kullanıcıya, kullanıma, tüketime, depolamaya ya da işlemlere göre mi lisanslanıyor? Ölçeklendikçe maliyete ne oluyor?

Sonra sınırlar vardır ve her platformda vardır: API, depolama, sorgu, işlem, eşzamanlılık, aktarım hızı ve lisans sınırları. Bazıları katı, bazıları esnek; bazıları yükseltilebilir, bazıları yükseltilemez; bazıları bizim ölçeğimizde fazladan bir sıfır ekleyene kadar önemsizdir. Her Salesforce sınırını ezberlemek zorunda değilsiniz; bunu yapmak zamanınızın berbat bir kullanımı olur. Bilmeniz gereken, sınırların var olduğu, hangilerinin mimariniz için önemli olduğu ve güncel sayıyı ne zaman doğrulamanız gerektiğidir. Sayılar değişecek. Mimari soru kalacak.

Çözümlü Bir Örnek: Apex Paylaşımı

İşte soruların iş başında olduğu en yaygın örneklerimden biri. Sahibe dayalı ya da ölçüte dayalı paylaşım kurallarının hiçbiriyle karşılanamayan karmaşık bir paylaşım gereksinimi alıyoruz. Bu bizi Apex paylaşımına götürüyor: paylaşım kayıtlarını kendisi yazan kod. Şimdi Apex paylaşımının ne olduğunu, nerede kullanıldığını, nasıl kullanılacağını ve geri kalanını bilmemiz gerekiyor. Bu bir tırmanmadır: ihtiyacımız olan kurallar sahibe ve ölçüte dayalı paylaşımın ifade edebileceğinin ötesine geçtiğinde Apex paylaşımı alternatiftir (4. soru).

Şimdi zayıf yanları (6. soru). Diyelim ki 10 ya da 20 milyon üyeli bir müşteri topluluğumuz var ve Customer Community Plus değil, Customer Community lisansını kullanıyoruz. Bunlar yüksek hacimli kullanıcılardır. Rolleri yoktur ve paylaşım modelini hiç kullanmazlar: erişimleri, hesapları ve kişileri üzerinden eşleşen paylaşım kümelerinden ve paylaşım gruplarından gelir. Apex’in onlar için yazacağı bir paylaşım kaydı yoktur, dolayısıyla Apex paylaşımı onlar için çalışmaz. Ve bizi oraya getiren maliyet ve lisans sorusudur (9. soru): lisans seçimi hangi paylaşım araçlarının var olduğunu belirlemiştir.

Yani Apex paylaşımı sahibe ve ölçüte dayalı kuralların alternatifi olduğu gibi, Apex paylaşımına bir alternatif bulmanız gereken bir durumla da karşılaşabilirsiniz. Ve o noktada karmaşık paylaşım kuralları için gerçekten yapılandırmaya dayalı bir seçenek kalmaz. Sonunda nesneyi salt okunur yapar ve erişimi Apex üzerinden kontrol edersiniz. Dokuz sorunun hepsini seçimden sonra değil, önce sormanızın nedeni budur.

Platformu Ezberlemeyin

Bu en çok Salesforce mimarisini öğrenirken önemlidir. Salesforce’u ezberlemeye çalışmayın. Yapamazsınız: platform çok büyük ve çok hızlı değişiyor. Uzun zamandır Salesforce ile çalışıyorum ve hâlâ öğreniyorum. Bu normaldir.

Geliştirmenizi istediğim şey bir öğrenme çerçevesidir. Salesforce yarın yeni bir yetenek yayımladığında onu daha önce görmüş olmam gerekmez. Ne soracağımı bilirim: nedir, nereye uyar, nasıl kullanırım, başka ne kullanabilirim, neyde iyidir, nerede zorlanır, nasıl açıklarım, nasıl işletirim ve maliyeti nedir, sınırları nerede? Artık onu değerlendirmeye başlayabilirim. Bu, bir özellik matrisini daha ezberlemekten çok daha değerlidir.

Sınavın ötesinde: yapay zekâ dokuz soruyu yanıtlamayı hızlandırır, yanlış yanıtlamayı da kolaylaştırır. Tanımadığınız bir teknolojiyle karşılaşın ve yapay zekâdan onu açıklamasını, üç yaklaşımı karşılaştırmasını, sınırlarını ve yaygın başarısızlık biçimlerini listelemesini ya da onu kullanmaya karşı argüman geliştirmesini isteyebilirsiniz. Bu olağanüstü bir araştırma asistanıdır. Ama yanılabilir, güncelliğini yitirmiş olabilir ya da benzer adlı iki ürünü veya sürümü kendinden emin biçimde karıştırabilir. Bir kararı etkileyen her şey için doğrulayın: kaynağı takip edin ve güncel belgeleri, sınırları ve lisansları kontrol edin. Güven ama doğrula (modül 7).

Yalnızca Cevapları Değil, Soruları Öğrenin

Bu kursta pek çok teknolojiyle karşılaşacağız. Cevap biriktirmenizi istemiyorum; soruları pratik etmenizi istiyorum. Büyük nesnelerden, harici veriden, Data 360’tan, entegrasyon kalıplarından ya da Salesforce’un bu bölüm yazıldıktan altı ay sonra yayımladığı bir yapay zekâ yeteneğinden bahsettiğimizde aynı dokuz soruyu sorun.

Cevaplar değişecek. Sorular kalıcıdır. Bunu bir çalışma rehberi değil de bir mimari çerçeve yapan da budur.

Araçlarınızı tanıyın: neyde iyi olduklarını, neyde kötü olduklarını, başka ne kullanabileceğinizi, maliyetlerini ve nerede bozulduklarını. Ve kararı onunla yaşamak zorunda olan insanlara açıklayacak kadar bilin. Bir mimar teknolojiyi böyle öğrenir.

Mimarın Burada Karar Verdikleri

• Bir aracın soruna uyup uymadığı; yalnızca yapılandırılıp yapılandırılamayacağına göre değil, dokuz sorunun hepsine göre değerlendirilerek.
• Alternatiflerin neler olduğu ve aracın maliyetinin, lisansının ve sınırlarının sizin ölçeğinizde ne anlama geldiği.
• Üç yıl sonra bakımını kimin ve nasıl yapacağı.
• Araç hakkındaki hangi gerçeklerin, onlara güvenmeden önce doğrulanacağı.

Daha Fazlası

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-09; yeniden kontrol 2026-10-12): yüksek hacimli kullanıcıların (External Apps, Customer Community, High Volume Customer Portal ve Authenticated Website lisansları) rolü yoktur; erişimleri paylaşım kümelerinden ve paylaşım gruplarından gelir; sahibe dayalı paylaşım kurallarına dahil edilemezler ve sahip oldukları kayıtlar manuel olarak paylaşılamaz.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (İngilizce, kontrol tarihi 2026-10-09; yeniden kontrol 2026-10-12): yüksek hacimli kullanıcılar (Customer Community, High Volume Customer Portal, Authenticated Website) lisansları rolleri desteklemediği için paylaşım modelini kullanmaz; erişim, kullanıcının Hesap ve Kişi arama alanlarıyla eşleştirilmesiyle, paylaşım kümeleri ya da paylaşım grupları aracılığıyla çalışır. Aynı sayfa Apex yönetimli paylaşımın ne zaman doğru araç olduğunu da listeler.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), Trailblazer Community sorusu, Kasım 2024 (İngilizce, kontrol tarihi 2026-10-09; yeniden kontrol 2026-10-12): bir uygulayıcı, yüksek hacimli kullanıcılar için paylaşım kayıtları eklemenin bir hatayla başarısız olduğunu bildiriyor. Resmî belge değil, sahadan bir rapor. (Çevrimiçi Trailblazer Community 30 Ekim 2026’da salt okunur hale geliyor; bağlantı değişebilir.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-09): bir paylaşım kümesi, kullanıcının hesabı ya da kişisiyle ilişkili kayıtlara erişim verir.