Bu modülün yanıtladığı soru: Verinin nereye gittiğini gösteren bir haritayı nasıl çizerim?
Bana yeni bir senaryo ve boş bir beyaz tahta verin, ilk çizeceğim şeylerden biri sistem haritası olur. Güzel değil, her API’yi içeren değil, henüz veri modeli değil. Kurumu görmek isterim: kullanıcıların kim olduğunu, hangi sistemlerin dahil olduğunu, Salesforce’un nerede durduğunu, onu neyin çevrelediğini, verinin nereden gelip nereye gittiğini. Sonra okları tek tek yürümek isterim. İyi bir harita kutuların resmi değildir. Mimari kararları açığa çıkarmanın bir yoludur.
CTA adaylarına bunun pratiğini yaptırırım. Senaryoyu okuyun, sonra çizmeye başlayın. Hepsini kafanızda çözene kadar beklemeyin; çizim çözmenize yardım eder. Birinci günden sonraki ödevin veri modeline bir deneme yapmadan önce haritaya başlamak olmasının nedeni bu. Önce veri modelini çizerseniz Salesforce’a neyin ait olduğunu zaten varsaymış olursunuz. Önce haritayı çizerseniz o kararı şekillendirmesi gereken sistemleri görebilirsiniz.
Yüksekten başlayın, sonra derine inin: önce kurumun tamamı, sonra önemli olduğu yerde ayrıntı.
Bir sistem haritasını çizmenin pek çok yolu vardır. Bu yalnızca benim yolum, yıllar içinde inceltip geliştirdiğim bir yol; bir haritayı nasıl hızla bir araya getireceğinizi görebilmeniz için paylaşıyorum. Her Salesforce haritası için kullanırım ve bir cümle gibi okunur: soldaki insanlar ortadaki Salesforce’a ulaşır; üstündeki sistemler aracılığıyla güvenilir, altındaki kanallar aracılığıyla hizmet verilir ve sağdaki arka ofise bağlanır.
Solda insanlar, yukarıdan aşağıya: iç kullanıcılar, ortaklar, müşteriler. Henüz her persona değil; bu mimariye kim ulaşmaya çalışıyor? sorusunu yanıtlamaya yetecek kadarı. Her grup içeri girdiği yeri gösterir: iç kullanıcılar Salesforce’u, ortaklar ortak topluluğunu, müşteriler müşteri topluluğunu. Sistemler kendi başlarına var olmaz. Biri ya da bir şey onları kullanmaya çalışıyordur.
6 adımdan 2.‘si: bu mimariye kim ulaşmaya çalışıyor?
Ortada Salesforce. Tek, sade bir kutu. Salesforce kurumun merkezi olduğu için değil (az önce üç modül boyunca öyle olmadığını söyledik), etrafında tasarım yaptığım sistem olduğu için. Çapadır.
Topluluklar hemen altında, ona değerek. Bir ortak topluluğu ve bir müşteri topluluğu ayrı uç noktalardır, bu yüzden kendi kutularını alırlar. Ama Salesforce’a yaslanırlar, çünkü onlara ulaşmak için hiçbir şeyin entegre olması gerekmez: aynı org’da çalışırlar.
6 adımdan 3.‘sü: ortada Salesforce, hemen altında topluluklar.
Üstte kimlik. Kimlik sağlayıcılar, geliştiricilerin unuttukları, en üste gider: biri iç kullanıcılar için, belki bir başkası ortaklar için. AppExchange paketleri de oraya, sağa kaydırılmış olarak gider, çünkü bunlar org’la veri alışverişi yapan arka ofis sistemleri değil, org’a getirilen yeteneklerdir. Herkese açık web siteleri sol üstte durur.
Sağda entegrasyon, sonra arka ofis. Entegrasyon katmanı, bir ESB ya da iPaaS (adı geçiyorsa MuleSoft), Salesforce’un hemen sağında uzun bir çubuktur. İç sistemler onun arkasında durur: ERP’ler, finans, sipariş yönetimi, eski sistemler, ambar. Artık sayfa soldan sağa okunur: insanlar, Salesforce, entegrasyon, arka ofis.
Altta kanallar. Müşterilere doğrudan hattı olan her şey: e-postadan vakaya (email-to-case), webden potansiyel müşteriye (web-to-lead), telefon, mesajlaşma.
Sağ altta veri girişi ve çıkışı. Harici veri kaynakları, arşivler, veri yüklemeleri.
Data 360 sağda, entegrasyon katmanının altında. Kullanıcılar ona hiçbir zaman bağlanmaz, kiracısı ise pek çok arka uç sisteme bağlanır; bu yüzden o hatların kısa kaldığı tesisatın yanında durur: iç sistemlerin, ambarın ve sağ alttaki verinin yanında. Veri ekipleri onun ekranlarını açar, ama bu ekranlar org’un içindedir: Data 360 çekirdeğe yakındır (near-core), çekirdekte yönetilir ve çekirdek dışında barındırılır (1. modül). Salesforce’a geri giden tek bir hat onu kimin yönettiğini gösterir. Kutuyu koyduğunuz yer, ne yaptığının hikâyesini anlatmalıdır.
Bu geometrinin hiçbiri kutsal değildir. Bir kuralın değeri, görsel dili her seferinde yeniden icat etmemem ve diyagramlarımdan birini görmüş herkesin bir sonrakini daha hızlı okuyabilmesidir.
Gösterimi basit tutun. Her sistem bir karttır: adı, rolü ve ne tür bir şey olduğunu söyleyen küçük bir simge: bir ERP, bir veritabanı, bir kimlik sağlayıcı, bir grup insan. Az önce anlattığım bölgeler soluk, etiketli alanlar olarak çizilir; böylece düzenin kendisi görünür olur. Alttaki bir gösterge, her simgenin ve çizginin ne anlama geldiğini söyler.
Bir kutunun içine çok fazla şey koymayın. Salesforce’u parçalarına (org’un içinde Sales Cloud ve Service Cloud, aralarında oklarla) yalnızca çok karmaşık bir haritada açarım. Ve her biri okuyucuya bir şey söylemedikçe on beş şekil icat etmeyin. Birinin haritaya otuz saniye bakıp mimariyi anlamaya başlamasını isterim. Süslü olmak yardım etmez. Açık olmak eder.
Hacmi düşünmek için ayrıntılı tasarımı beklemeyin. Gecede 500 ürün taşıyan bir ok ile günde 200.000 GPS okuması taşıyan bir ok haritada tıpatıp aynı görünebilir. Aynı sorun değillerdir. Bu yüzden tek bir ok çizmeden önce neyin hareket ettiğini sayın. Resmin arkasındaki envanteri sayılarla başlatın: her önemli veri kümesi için hacmiyle birlikte bir satır. Sıfırlar oklarda hiç görünmeyebilir, ama yüksek sayılara ne zaman geçtiğinizi bilmeniz gerekir: bir saatte binlerce ya da milyonlarca, yüz binlerce işlem, hatta saniyede onlarca ila yüzlerce işlem.
Bu sayılar mekanizmayı belirler. Gecede birkaç yüz kayıt bir toplu iştir. Birinin beklediği bir çağrı, hacim izin veriyorsa eşzamanlı olabilir. Saniyede onlarca ila yüzlerce kayıt, kayıt başına bir çağrı yerine platform olayları gibi olaylar gerektirebilir. Ok aynı görünecektir; onu neyin taşıyacağına hacim karar verir, bu yüzden onu mekanizmanın seçildiği yere, envantere kaydedin.
Mekanizma okun yönünü bile değiştirebilir. Dakikada birkaç kayıt gönderin, Salesforce basitçe dışarıyı çağırabilir: ok Salesforce’ta başlar. Çok daha fazlasını gönderin, Salesforce bunun yerine olay veri yolunda olaylar yayımlayabilir; harici sistem abone olur ve onlar için içeriyi çağırır, böylece ok artık diğer uçta başlar. Daha da büyüğü, diyelim milyonlarca kaydın gece senkronizasyonu, bir toplu iş sürecidir. Dolayısıyla mekanizmaları tasarlamaya başlarken sayılarınızı erkenden bilin, çünkü sayılar okları yeniden çizebilir.
Hacim iki yerde, iki nedenle önemlidir. Bir veri modelinde, büyük veri hacimlerini gözetmek ve arşivlemeyi planlamak için ona ihtiyacım var; 2. Kısım bunu derinlemesine ele alıyor. Bir sistem haritasında, envanterdeki büyük sayılar entegrasyon kalıbının ve mekanizmanın seçimini belirler. 6. modül Steve Trucking’in haritasına ve envanterine gerçek sıfırlar koyuyor. Sayılar elinizdeyken okları çizin.
Sistemler yerine oturduğunda onları bağlayın ve harita mimariye dönüşür. Kutu bir sistemdir; ok bağlantıyı kimin başlattığını gösterir. Bağlantıyı açan sistemde başlar ve çağırdığı sistemi gösterir: istemciden sunucuya. Etiket neyin hareket ettiğini ve hangi yöne gittiğini söyler.
Bu kural, sistemlerin sistemlerle konuştuğu sistem haritaları içindir. Bir veri akışı diyagramında ok, beklediğiniz gibi veriyi izler. Harita kuralını başka diyagramlara taşımayın; yalnızca kafa karışıklığı ekler.
Oklar eklendi. Her kutu olduğu yerde; her ok bağlantıyı açan sistemde başlar ve etiketi neyin hangi yöne hareket ettiğini söyler.
Yani entegrasyon katmanı ürünleri Salesforce’a itiyorsa ok entegrasyon katmanından Salesforce’a gider ve gelen ürünler etiketini taşır. Salesforce onları almak için dışarıyı çağırıyorsa ok Salesforce’ta başlar, etiketi yine gelen ürünlerdir. Aynı veri, farklı konuşma; ve bu fark bana kimlik bilgilerine kimin ihtiyaç duyduğunu ve hatayı kimin ele alması gerektiğini söyler. Salesforce siparişi entegrasyon katmanı üzerinden gönderir: giden siparişler. ERP’nin karşılama bilgisi geri gelir: gelen sipariş durumu. Artık her konuşmayı kimin başlattığını, verinin Salesforce’a nerede girip nerede çıktığını, hangi akışların sınırları geçtiğini, sahipliğin muhtemelen nerede olduğunu ve nerede daha fazla soru sormam gerektiğini görebilirim.
Ve 1. modülü hatırlayın: yalnızca tek bir akış gördüğümde endişelenirim. Üst düzeyde bir giden siparişler oku geri akışlara bağlıdır: gelen müşteriler, gelen ürünler, fiyatlar. Daha da derine bakın, dönüş yolculuğu oradadır: kabul, ret, durum, bir fatura numarası, bir iptal. Oklar bana itiraz edecek somut bir şey verir.
Haritanın PowerPoint süsü olmaktan çıktığı yer burası. İnceleme kurulunda herhangi bir ok üç soru getirebilir ve yanıtlarının sizde olmasını isterim:
Nasıl kimlik doğruluyor? OAuth, bir sertifika, adlandırılmış bir kimlik bilgisi (named credential), başka bir şey?
Eşzamanlı mı, eşzamansız mı? Salesforce ERP’yi bekliyor mu, yoksa yayımlayıp devam mı ediyor? İşin sonuca ne kadar hızlı ihtiyacı var?
Mekanizma ne? Bir REST çağrısı, bir olay, bir dosya, bir mesaj kuyruğu; MuleSoft üzerinden mi, doğrudan mı?
Ve sonra: karşı taraf çöktüğünde ne olur? Her okun bir mekanizmaya ihtiyacı vardır. Açıklayamıyorsanız çizgi süstür.
Ve “gönder ve unut” bir yanıt değildir. Genellikle “gönderdikten sonra ne olacağını tasarlamadım” anlamına gelir. Ulaştı mı? Kabul edildi mi? Başarısız mı oldu? Yeniden denenecek mi? Takıldığını kim biliyor? Aynı mesaj iki kez gelirse ne olur? Bunların hiçbiri haritaya girmez, yoksa okunamaz hale gelir. Ama ok, bu soruların var olduğunu size bildirmelidir.
Herhangi bir oka yakından bakın; bir istemci ve bir sunucu vardır ve her biri kendi yarısının sahibidir. İstemci bağlantıyı açar: uç noktaya ve porta ihtiyaç duyar, önce kimlik doğrulama sunucusundan bir belirteç alır, sunucunun tanımladığı protokolü ve sözleşmeyi çağırır ve bekleyip beklemeyeceğini seçer. Gidiş-dönüşün tamamını yalnızca istemci görür, bu yüzden yalnızca istemci yeniden deneyebilir. Sunucu dinler; protokolü, sözleşmeyi ve yükü tanımlar, gelen şeyi doğrular ve yalnızca kendi kısmını görür. Bir ok çizdiğimde hangi ucun hangisi olduğunu zaten bilirim ve bu bana bu soruların her birinin sahibinin kim olduğunu söyler.
Yakından bakılan tek bir ok: istemci ele alır, sunucu tanımlar. Bunların hiçbiri haritaya girmez, ama her okta vardır.
Şimdi oku ters çevirin. ERP Salesforce’u çağırdığında sunucu Salesforce’tur: API’leri tanımlar, kendi yetkilendirme sunucusunu çalıştırır ve çağıranın ne yapabileceğine bir External Client App ve bir entegrasyon kullanıcısı aracılığıyla karar verir. Aynı sorular, diğer taraf.
Mimarların iyi bir diyagramı mahvettiği yer burası: tek bir eserin her şeyi yanıtlamasını isterler. Haritaya API adları, yükler, yeniden denemeler, hata kuyrukları, dönüşümler, her geri çağrı eklenir ve çok geçmeden kimse onu okuyamaz. Yapmayın. Harita büyük resimdir: sistemler ve aralarındaki önemli akışlar.
Bir etkileşimi açıklamam gerektiğinde ikinci bir diyagram çizerim, ama her entegrasyon için değil. A sistemi B’ye bir şey gönderiyorsa ya da bir şey sorup yanıt alıyorsa etiketli ok yeterlidir. Süreç bir konuşmaya dönüştüğünde bir kulvar diyagramı (swim lane) isterim: A, B’yi çağırır, B, C’ye danışır, C yanıt verir, B bir şey oluşturup A’yı geri çağırır, bir kişi onaylar, başka bir sistem devam eder. Kabaca kuralım: bir iki taneden fazla karşılıklı alışveriş varsa sıralama kendi kulvarını alır. Haritada oklar; konuşma kulvarda.
Ve orada bir okun farklı bir anlama geldiğine dikkat edin. Haritada ok bir bağlantıdır: onu kim açar ve ne hareket eder. Bir kulvarda her ok, sırayla okunan bir konuşmadaki tek bir mesajdır: bir istek bir yöne gider, bir yanıt diğer yöne geri gelir ve sonraki adım izler.
Harita büyük ölçüde bitmiş göründüğünde onu ok ok yürüyün. ERP’den Salesforce’a: ne hareket ediyor, sahibi kim, nasıl kimlik doğruluyor, mekanizma ne, eşzamanlı mı eşzamansız mı, ne kadar güncel olmalı? Sonra bir sonraki ok ve bir sonraki. Boşlukların ortaya çıktığı yer burasıdır. “Ah, ortağın onu gerçekte nasıl gönderdiğini hiç çözmedik.” “Siparişleri ERP’ye gönderiyoruz, ama reddedilenlerin nasıl geri geleceğini tasarlamadık.” Güzel. Onu canlı ortamda değil, beyaz tahtada buldunuz.
Resim okunabilir kalmalı; bu yüzden ayrıntılar arkasındaki envantere gider. Onu sayılarla başlattınız; şimdi tamamlayın, her önemli veri kümesi ya da akış için bir satır:
Sütun
Bilmek istediğim
Veri kümesi
Müşteri, ürün, sipariş, teslimat, fatura
Tür
Ana, referans, işlem, analitik, yapılandırılmamış
Sahip
Anlamının ve yaşam döngüsünün sahibi kim?
Kayıt sistemi
Esas sürüm nerede?
İş yükü
Operasyonel, analitik, akış
Hacim
Sıfır Sayısı
Org
Birden fazla varsa hangi Salesforce org’u?
Kimlik doğrulama
Bağlantı güveni nasıl kuruyor?
Mekanizma ve zamanlama
API, olay, dosya, federasyon; eşzamanlı, eşzamansız, toplu
Yaklaşım
Kopyala mı, başvur mu, federasyonla mı eriş?
Artık iki eser var: harita mimariyi görmemi, envanter de onu sorgulamamı sağlar.
Bu eseri sevmemin nedeni bu: düşünmeme yardım ediyor. “Salesforce ve ERP genelinde nasıl raporlama yapacağız?” Bu 3. modüldeki soru: diyagramlarımdan hangisi bunu harika çözüyor? Harita. Her şey çekirdekteyse standart raporlar. Veri ERP’de ve ambardaysa bunu hemen görebilirsiniz. “Bu müşteri özniteliğinin ana kaynağı nerede olmalı?” Hangi sistemlerin onu kullandığına ve müşterinin sahibinin zaten hangisi olduğuna bakın. “Salesforce’un her GPS okumasına ihtiyacı var mı?” Onu kim üretiyor, kim tüketiyor, iş yükü ne? Belki Salesforce’un güncel konuma ihtiyacı vardır, geçmişi başka bir platform tutar. Harita size yanıtı vermez. Size sorunun doğru görünümünü verir.
Bir disiplin daha. Var olan bir kurumda, var olmasını dilediğinizi değil, var olanı çizin. Her Cuma e-postayla gönderilen elektronik tablo: çizin. Ortağın bir SFTP sunucusundaki CSV’si: çizin. Tarihsel nedenlerle ESB’yi atlayan entegrasyon: çizin. İki sistem arasında veriyi elle yeniden giren insanlar: gösterin. Belgelerken gerçekliği temizlemeyin. Hedef haritayı tasarlamadan önce mevcut haritaya ihtiyacınız vardır ve Steve Trucking için 6. modülde yaptığımız da budur.
Sınavın ötesinde: yapay zekânın değiştirdikleri. Harita bir ajan haritasına dönüşüyor. Bir ajan “teslimatım nerede?” sorusunu yanıtlıyorsa harita, yanıtın Salesforce’tan mı, bir ortak sisteminden mi, telematikten mi, ERP’den mi yoksa bir karışımdan mı geldiğini söylemelidir. Ajanlar sistem sınırlarını ortadan kaldırmaz; hangi sistemin esas olduğunu ve ona nasıl güvenle ulaşılacağını bilmeyi daha da önemli hale getirir.
Haritaya hangi sistemlerin ve kullanıcı kitlelerinin ait olduğu ve yerleşimlerinin rollerini nasıl gösterdiği.
Hangi akışların sistem sınırlarını geçtiği, hangi yönde ve ne geri geldiği.
Her bağlantının nasıl kimlik doğruladığı, onu hangi mekanizmanın taşıdığı ve eşzamanlı mı, eşzamansız mı, toplu mu yoksa federasyonla mı olduğu.
Etiketli bir okun ne zaman yeterli olduğu ve bir etkileşimin ne zaman kendi kulvarına ihtiyaç duyduğu.
Resmin arkasındaki envanterin neyi kaydettiği: sahip, iş yükü, hacim, org, zamanlama, kimlik doğrulama ve kopyalama, başvurma ya da federasyon.
Harita, mimari bittikten sonra çizdiğim bir şey değildir. Mimariyi bulma yolumdur. Ve bittiğini düşündüğünüzde ona hayran kalmayın. Yürüyün. Henüz açıklayamadığınız her ok size işin nerede olduğunu gösterir.
