Tersinirlik Testi
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)
Data Architect kursunun ilk bölümü olan Bir Veri Mimarı Gibi Düşünmek bölümündeki 7 modülden 3.‘sü. Her modül kendi başına okunabilir. Önceki: Veri Modeli İskelettir · Sonraki: Mimari, Ödünleşim Sanatıdır
Bu modülün yanıtladığı soru: Mimari bir kararı sıradan bir karardan nasıl ayırt edersiniz?
Mimarlar pek çok karar verir.
Ama her karar mimari bir karar değildir.
Bu önemli bir ayrımdır. Her kararı mimari olarak ele alırsak, bütün zamanımızı değiştirilmesi görece kolay şeyleri tartışarak geçiririz. Gerçekten mimari olan kararları fark etmezsek, bugün beş dakikada verdiğimiz bir kararı çözmek beş yıl sürebilir.
Peki farkı nasıl anlarız?
Basit bir soru sormayı severim:
Bu kararı daha sonra geri almak ne kadar zor olacak?
Buna Tersinirlik Testi diyorum.
Bir şeyi geri almak ne kadar zorsa ve ona ne kadar çok şey bağlı olacaksa, o kadar mimari ilgiyi hak eder.
Bazı Kararları Değiştirmek Ucuzdur
Bölüm başlığı “Bazı Kararları Değiştirmek Ucuzdur ”Basit bir şeyle başlayalım.
Bir alana Customer Category (Müşteri Kategorisi) adını veriyoruz. Altı ay sonra iş birimi herkesin aslında ona Customer Segment (Müşteri Segmenti) dediğine karar veriyor. Etiketi değiştiriyoruz. Güncellenecek biraz belge ve biraz kullanıcı eğitimi olabilir, ama bu büyük bir mimari olay değil. Yine de özgün API adıyla yaşamak zorunda kalacağız, çünkü onu değiştirmenin sonuçları çok daha büyük. Yani bu, bir etiket değişikliğiyle ve onunla gelebilecek kafa karışıklığıyla uğraşmak anlamına gelebilir.
Bir karar verdik. Fikrimizi değiştirdik. Yolumuza devam ettik.
Şimdi bunu farklı bir kararla karşılaştırın.
Müşteriler için bir tanımlayıcı oluşturuyoruz. Ne anlama geldiğine, hangi biçimi kullandığına ve hangi sistemin onu ürettiğine karar veriyoruz. Sonra onu yayımlıyoruz.
Salesforce onu kullanıyor. Veri ambarı onu kullanıyor. Entegrasyon platformu onu kullanıyor. Müşteri portalı onu kullanıyor. Beş başka uygulama onu saklamaya başlıyor. Raporlar ve veri hatları onu kullanıyor. Belki sonunda müşteriler de onu görüyor.
Üç yıl sonra biri şunu söylüyor:
Tanımlayıcıyı muhtemelen bu şekilde tasarlamamalıydık.
Bu çok farklı bir konuşmadır.
Fark, bir kararın diğerinden daha teknik olması değildir.
Fark tersinirliktir.
Bu şöyle olabilir. Diyelim ki işletme anahtarlarını müşterinin adının bir parçası ile bir numaradan oluşturuyor. Yıllarca işe yarıyor, çünkü kimse hiç ad değiştirmek zorunda kalmamış. Sonra bir yıl ya da daha uzun bir süre sonra bir ad gerçekten değişiyor ve anahtarlar birdenbire verinin geri kalanının beklediği kalıba uymaz hale geliyor. Anahtarların içsel bir anlam taşımaması gerekmesinin nedenlerinden biri budur.
Mimari Çekim Gücü Yaratır
Bölüm başlığı “Mimari Çekim Gücü Yaratır ”Mimari bir karar etrafında bir şeyler biriktirme eğilimindedir. Ben buna çekim gücü diyorum.
Bir nesne modeli seçin, etrafında otomasyon kurulur.
Bir anahtar seçin, diğer sistemler onu saklamaya başlar.
Ana verinin nerede yaşayacağını seçin, entegrasyonlar ona doğru ve ondan uzağa akmaya başlar.
Bir paylaşım modeli seçin, iş süreçleri kimin neyi görebildiğine bağlanmaya başlar.
Bir entegrasyon kalıbı seçin, sistemler onun zamanlamasına ve davranışına bağlanmaya başlar.
Bu kararlar ne kadar uzun süre var olursa o kadar çekim gücü kazanırlar. Sonunda özgün kararı değiştirmek, etrafında biriken her şeyi değiştirmek anlamına gelir.
Yapay zekâ da bu çekim gücünü hisseder. Bir yapay zekâ aracı sistemde zaten var olandan yola çıkarak çalışır: kilit bir tasarım öğesi bir kez oraya girdiğinde, ondan sonraki her yapay zekâ etkileşimi o öğeyi bir gerçek olarak kabul eder ve onun üzerine inşa etmeye, inşa etmeye, inşa etmeye devam eder. Karar ileriye doğru pek çok başka kararda yankılanır ve hiçbir insan özgün karara geri dönüp onu yeniden ele almaz. Her üretim çekim gücünü biraz daha artırır.
Veri modelinin “iskelet” olmasının önemli olmasının nedeni budur. Değişim kötü olduğu için dikkatli değiliz. Bağımlılıklar değişimi pahalı hale getirdiği için dikkatliyiz.
İki Soru Sorun
Bölüm başlığı “İki Soru Sorun ”Bir tasarım kararına baktığımda iki soru sorarım:
Bunu geri almak ne kadar zor?
Ona ne kadar şey bağlı olacak?
Birbirleriyle ilişkilidirler ama aynı değildirler. Bir şeyi teknik olarak değiştirmek kolay olabilir ama yüzlerce kullanıcısı olabilir. İnsanlar eskiden standart nesneleri anlaşılır olsun diye yeniden etiketlerdi, örneğin Hesap’ı “Customer” olarak. Yapması kolaydı. Sonra başka bir sistem Hesapları İş Ortakları için kullanmak istedi ve kullanamadı. Başka bir şeyin ise yalnızca birkaç kullanıcısı olabilir ama değiştirmek devasa bir taşıma gerektirebilir; içeride pek çok yerden başvurulan bir nesnenin API adı gibi. Dışarıdan kimse görmez ama yanlış bir ad ekibin kafasını karıştırmaya devam eder. İkisi de ilgiyi hak eder.
Bazı yaygın veri kararlarını düşünün:
- Bu iş kavramını hangi Salesforce nesnesi temsil ediyor?
- Benzersiz tanımlayıcı nedir?
- Kayıt sistemi hangi sistem?
- Bu veri Salesforce’a mı kopyalanıyor, yoksa başka bir yerde mi erişiliyor?
- Bu tek bir nesne mi, yoksa birkaç ilişkili nesne mi?
- Verinin sahibi kim ve onu ne kadar süre saklıyoruz?
- Varsayılan erişim sınırlarımız neler?
- Bu veri sistemler arasında nasıl hareket ediyor?
Bunlar bir alanın Lightning sayfasında nerede görüneceğine karar vermekten çok farklıdır. Sayfa tasarımı da önemlidir. Yanılmanın maliyeti farklıdır.
Etki Alanını Düşünün
Bölüm başlığı “Etki Alanını Düşünün ”Tersinirliği düşünmenin bir başka yolu da etki alanıdır: bu kararı değiştirirsem başka ne yerinden oynar?
Diyelim ki alan olarak modellediğimiz bir şeyin gerçekte bir alt nesne olması gerekiyor. Bu yalnızca bir şema değişikliği değildir. Mevcut veriye ne olacak? Raporlara, o alanı bekleyen entegrasyonlara, ona başvuran Apex ve Flow’lara, güvenliğe, analizlere, eylemleri özgün yapıya bağlı olan bir yapay zekâ ajanına ne olacak?
Etki alanı ne kadar büyükse, özgün kararı o kadar dikkatli vermeliyiz.
Mimarların sistemin kendi parçalarının ötesine bakmak zorunda olmasının nedeni de budur. Salesforce’un içinden bakıldığında bir değişiklik kolay görünebilir. Kurum genelinden bakıldığında on iki başka sistemi etkileyebilir.
Kurumsal Kararlar ve Salesforce Kararları
Bölüm başlığı “Kurumsal Kararlar ve Salesforce Kararları ”Bir Veri Mimarı iki düzeyde düşünür.
Salesforce’un içinde nesnelere, ilişkilere, anahtarlara, hacme, erişime, otomasyona ve verinin platformda nasıl davrandığına karar veririz.
Kurum genelinde daha geniş sorular sorarız. Müşteri (Customer) gerçekte nerede yaşıyor? Ürünün sahibi kim? Bir Siparişi hangi sistem oluşturuyor? Yetkili tanımlayıcımız nedir? Hangi bilgi sistemler arasında kopyalanıyor ve hangisi olduğu yerde kalıyor?
İki düzeyin birbirine bağlanması gerekir. İç modelin kendi başına gayet mantıklı olduğu ama etrafındaki kuruma uymadığı Salesforce uygulamaları gördüm. Bu yeterli değildir. Salesforce yapılarının kurumsal düzeyde temsil edilmesi, kurumsal kararların da Salesforce’a geri akması gerekir.
Mimari çift yönlü bir trafiktir.
Pahalı Kararları Yavaşlatın
Bölüm başlığı “Pahalı Kararları Yavaşlatın ”Teknolojideki tehlikelerden biri, uygulaması en kolay kararların vermesi de en kolay kararlar gibi görünebilmesidir. Aynı şey değildirler.
Bir özel nesne daha oluşturmak kolaydır. Bir alan daha oluşturmak kolaydır. Bir API daha bağlamak giderek kolaylaşıyor ve yapay zekâ bunların hepsini daha da kolaylaştırıyor.
Ama uygulamanın kolaylığı bize mimari kararın maliyeti hakkında neredeyse hiçbir şey söylemez.
Geri alınması zor bir karardan önce şunları sormaya yetecek kadar yavaşlayın: Gerçekte hangi sorunu çözüyoruz? Hangi alternatifleri değerlendirdik? Neyi varsayıyoruz? Hacim büyüdükçe ve iş değiştikçe ne olur? Başka ne buna bağlı olacak? Yanılıyorsak ne olur?
Her nesne oluşturduğumuzda altı aylık bir incelemeye ihtiyacımız yok. Ama yanılmanın maliyetiyle orantılı bir düşünceye ihtiyacımız var. Tek bir departman ya da alt sistem için bir nesneyse daha hızlı hareket edebilirsiniz. Referans verisiyse, kilit bir müşteri nesnesiyse ya da sistemler arasında kullanılan bir şeyse, iyice düşünmek için zaman ayırın.
Nedenini Yazın
Bölüm başlığı “Nedenini Yazın ”Önemli kararlarla ilgili bir sorun daha var: insanlar neden verildiklerini unutur.
Biri üç yıl sonra bir mimariye bakar ve “Kim böyle tasarlar ki?” diye sorar. Bazen cevap, bunun kötü bir tasarım olduğudur. Oluyor. Ama bazen çok iyi bir neden vardı: artık var olmayan bir platform sınırlaması, bir düzenleyici gereksinim, tercih edilen yaklaşımı destekleyemeyen başka bir sistem, bir son tarihe yetişmek için bilerek kabul edilen bir ödünleşim.
Yalnızca neye karar verdiğimizi kaydedip nedenini kaydetmezsek, bir sonraki mimarın bunu bilmesinin hiçbir yolu olmaz.
Önemli kararlar için bunu yazın. 50 sayfalık bir belge olması gerekmez. Faydalı bir karar kaydı çok küçük olabilir:
Bağlam: Hangi sorunu çözüyoruz?
Seçenekler: Hangi gerçekçi alternatifleri değerlendirdik?
Karar: Neyi seçtik?
Sonuçlar: Ne kazanıyoruz ve neden vazgeçiyoruz?
Sahip: Bu karardan kim sorumlu?
Gözden geçirme: Hangi neden ya da tarih bize onu yeniden ele aldırmalı?
Değer belgede değildir. Değer gerekçeyi korumaktadır.
Ve bir karar değiştiğinde özgün kararı silmeyin. Onun yerine yenisini koyun. 2027’de doğru olan karar 2030’da doğru olmayabilir, çünkü hacimler, iş, Salesforce ve bizim anlayışımız değişir. Korumak istediğim şey hikâyedir: bağlam buydu, karar buydu ve nedeni buydu, değişen şu oldu ve şimdi buna karar veriyoruz. Bu, cevabı hep biliyormuş gibi yapmaktan çok daha değerlidir.
Sınavın ötesinde: yapay zekâ karar ile bağımlılık arasındaki süreyi kısaltır. Bir yapay zekâ aracı saniyeler içinde bir veri modeli önerebilir, sonra onun üzerine nesneleri, otomasyonu, entegrasyon kodunu ve kullanıcı arayüzünü oluşturabilir. Şüpheli bir kararın üzerine çok şey bağlanması eskiden aylarca geliştirme gerektirirdi; şimdi bağımlılıklar neredeyse anında gelir. Bu yüzden yalnızca çıktıyı değil, çıktının altındaki kararları inceleyin. Yapay zekâ yardımcı olabilir: seçenekleri listeleyebilir, varsayımları sorgulayabilir ve karar kaydının taslağını yazabilir. Ama kararı yine mimar verir ve karar ne kadar zor geri alınırsa insan muhakemesi o kadar önemlidir.
Hangi Kararların Önemli Olduğunu Bilin
Bölüm başlığı “Hangi Kararların Önemli Olduğunu Bilin ”Geliştirmenizi istediğim becerilerden biri dikkatinizi nereye harcayacağınızı bilmektir.
Her yapılandırma seçimini bir mimari zirvesine dönüştürmeyin.
Ama kurumun önümüzdeki on yıl boyunca yaşayacağı bir kararı da gelişigüzel vermeyin.
Şunu sorun:
Bunu geri almak ne kadar zor olacak?
Ona ne kadar şey bağlı olacak?
Cevaplar çok zor ve çok şey ise, muhtemelen mimari bir karar buldunuz.
Yavaşlayın. Gereksinimi anlayın. Alternatifleri keşfedin. Ödünleşimleri görünür kılın. Kararı verin. Ve nedenini yazın.
Mimarinin amacı asla değişemeyecek kararlar vermek değildir.
Amaç, fikrinizi değiştirmenin pahalı olacağı kararları fark etmektir.
Mimarın Burada Karar Verdikleri
Bölüm başlığı “Mimarın Burada Karar Verdikleri ”- Hangi kararların mimari olduğu: geri alınması zor ve onlara çok şey bağlı.
- Her kararın yanılmanın maliyetiyle orantılı olarak ne kadar ilgi göreceği.
- Hangi kararların bağlamı, seçenekleri, sonuçları, sahibi ve gözden geçirme noktasıyla birlikte yazılacağı.
- Salesforce kararlarının kurumun kararlarıyla nasıl hizalandığı.
Daha Fazlası
Bölüm başlığı “Daha Fazlası ”- Object Relationships Overview (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-09; yeniden kontrol 2026-10-12): ana-ayrıntı ilişkisinde ayrıntı kaydının erişimi ve sahipliği ana kaydı izler ve bir ana kaydı silmek onun ayrıntılarını da siler.
- Considerations for Object Relationships (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-09; yeniden kontrol 2026-10-12): bir arama ilişkisi ancak her kayıtta bir değer varsa ana-ayrıntı ilişkisine dönüştürülebilir; dönüştürmek paylaşım modelini değiştirir (Controlled by Parent, yani üst kayıt tarafından denetlenen) ve hangi standart rapor türlerinin kullanılabileceğine ilişki türü karar verir.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-10-09; yeniden kontrol 2026-10-12): toplama özetleri yalnızca ana-ayrıntı ilişkilerinde vardır ve bir ana-ayrıntı ilişkisi arama ilişkisine dönüştürülmeden önce silinmeleri gerekir.