Mimari, Ödünleşim Sanatıdır

🌐 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 4.‘sü. Her modül kendi başına okunabilir. Önceki: Tersinirlik Testi · Sonraki: Bugün İçin İnşa Edin. Yarın İçin Planlayın. Başarısızlık İçin Planlayın.

Bu modülün yanıtladığı soru: Birkaç çözüm işe yarayabildiğinde bir mimar nasıl seçer ve seçimini nasıl açıklar?

Mimari yalnızca doğru cevabı bulmaktan ibaret olsaydı çok daha kolay olurdu. Platformu öğren, kalıpları öğren, sınırları öğren, doğru olanı seç, bitti.

Gerçek mimari böyle işlemez. Zor kararlar genellikle açıkça iyi bir çözüm ile açıkça kötü bir çözüm arasında değildir. İşe yarayabilecek birkaç çözüm arasındadır; her birinin avantajları ve dezavantajları vardır ve her biri mimariyi biraz farklı bir yöne götürür. Mimar masadaki yerini tam da burada hak eder.

Sorunu Çözmenin Pek Çok Yolu

Mimarlara ders verirken bu örneğin bir versiyonunu defalarca kullandım.

Salesforce’ta bir sorunu çözmenin pek çok yolu olabilir. Bazen buna bir sayı veririm, mesela on, ama bu bir benzetmedir, bir sayım değil. Seçeneklerin birçoğu baştan sorunludur: bir platform kısıtına takılırlar, kritik bir gereksinimi kaçırırlar ya da kabul edemeyeceğimiz bir güvenlik veya performans sorunu yaratırlar. Bunları hızla bir kenara koyabiliriz. Bazıları ise bugün çalışır ama veri büyüdüğünde sorun çıkarır. Teknik olarak işlevseldirler ama zaten geleceğini bildiğimiz büyümeye dayanamazlar.

Geriye ileride ihtiyaçlarınızı karşılayabilecek az sayıda seçenek kalır ve iş burada ilginçleşir. Her biri işe yarayabilir, ölçeklenebilir ve gereksinimleri karşılayabilir. Peki hangisi doğru? Belki hepsi. Mimarın işi aralarındaki farkları anlamaktır.

Seçim listesi kadar basit bir şey bile bugün çalışır ve veri büyüdükçe sorun çıkarabilir. Seçim listesi kullanıcılar için kolaydır. Ama değerlerin nereden geldiğini ve kaç tane olabileceğini sorun. Seçim listeleri yaklaşık 20’den az değerle en iyi çalışır. Bazen 50’ye çıkarız, ABD eyaletleri gibi; nadiren 100’ü geçeriz, ülkeler gibi; bunlar da hantallaşır. Bu yüzden her seçim listesi için üst sınırı bilin. Ve bir seçim listesinin değerlerini değiştirmek bir veri değişikliği değil, bir meta veri değişikliğidir.

Bunun yerine bir arama ilişkisi kullanırsanız kullanıcı arayüzü biraz karmaşıklaşır. Ama liste üst sınır olmadan büyümeye devam edebilir ve yeni değerler bir entegrasyondan gelebilir. Bu, kullanılabilirliğe karşı bir ödünleşimdir. Denge budur.

Click to enlarge

En Uygun, Mükemmel Demek Değildir

En uygun kelimesini dikkatle kullanırım. En uygun mimari, her bir kararın mükemmel olduğu bir mimari değildir; böyle bir mimari muhtemelen yoktur. Genel çözümün dengeli olduğu bir mimaridir.

Diyelim ki A Çözümü en iyi performansı veriyor ama pahalı ve bakımı zor. B Çözümü daha ucuz ve işletmesi daha kolay ama biraz performanstan vazgeçiyor. C Çözümü gelecek için daha esnek ama bugün karmaşıklık ekliyor. Hangisi en uygun? Yalnızca bu gerçeklerden yola çıkarak cevap veremem. İşi, gereksinimleri ve öncelikleri bilmem, hangi kısıtların gerçek, hangilerinin tercih olduğunu bilmem gerekir. Mimari bağlama bağlıdır. Bir müşteri için doğru olan kalıbın bir sonraki müşteri için tamamen yanlış olabilmesinin nedeni budur.

Ve bir Veri Mimarı olarak işiniz bu kararları dengelemektir. Onlarcasını kendiniz ya da ekibinizle vereceksiniz. Bunların hangileri olduğunu bilin ve bir kararın maliyet, zaman ya da işlevsellik açısından ne zaman daha büyük bir etkisi olduğunu ve kilit karar vericilere çıkması gerektiğini bilin.

En Uygun Olmayan Bir Karar, En Uygun Bir Mimarinin Parçası Olabilir

Bu, bu bölümün en önemli fikirlerinden biridir. Bazen bütün çözümü daha iyi hale getirdiği için mimarinin bir bölümünde bilerek en uygun olmayan bir karar veririm.

Belki az miktarda veriyi çoğaltırım, çünkü çoğaltmayı kaldırmak gereksiz entegrasyon karmaşıklığı yaratır. Belki daha basit bir veri modeli seçerim, çünkü teorik olarak daha temiz olanı raporlamayı ve günlük kullanımı çok zorlaştırır. Belki küçük bir performans maliyetini kabul ederim, çünkü alternatif, kurumun işletmeye hazır olmadığı bir altyapı ekler.

Bunlardan herhangi birine tek başına bakarsanız en uygun olmadığını söylersiniz. Doğru. Ama mimari her bileşeni kendi başına en uygun hale getirmekle ilgili değildir; sistemi en uygun hale getirmekle ilgilidir. Yerel olarak en uygun olmayan bir karar, yaptığımız ödünleşimi anladığımız sürece küresel olarak en uygun bir mimarinin parçası olabilir. Tehlikeli olan, ödünleşimi yaptığınızı bilmeden yapmaktır.

Neden Vazgeçtiğinizi Bilin

Biri bana “en iyi çözüm bu” dediğinde bir sonraki sorum “neyde en iyi?” olur. En hızlı mı? En ucuz mu? En basit mi? En ölçeklenebilir, en güvenli, en esnek mi? İşletmesi en kolay, teslimi en hızlı, uzmanlaşmış becerilere en az bağımlı olan mı? Neredeyse her zaman cevabın “en iyi” olmadığı başka bir boyut vardır. İşte ödünleşim odur. Ne elde ettiğimizi bilmek isterim, neden vazgeçtiğimizi de bilmek isterim.

Büyük bir kurumsal veri kümesi için iki seçeneği ele alalım. Biri veriyi Salesforce’a kopyalar; bu, Salesforce’un yerel yeteneklerini kullanmayı kolaylaştırır, ama artık veriyi taşımaktan, saklamaktan, senkronize etmekten, bir kopyayı daha güvence altına almaktan ve gecikmeyle uğraşmaktan biz sorumluyuz. Diğeri veriyi olduğu yerde bırakır ve gerektiğinde ona erişir. Bir miktar çoğaltmayı ortadan kaldırdık ama artık erişilebilirlik, sorgu performansı, ağ bağımlılıkları ve uzak sistemin yetenekleri daha önemli. İki açıklama da bize hangisini seçeceğimizi söylemiyor. Bize hangi soruları soracağımızı söylüyor.

Gereksinimler Eşit Değildir

Ödünleşimler bizi her gereksinimin aynı ağırlığı taşımadığını görmeye de zorlar.

Biri “Verinin anında kullanılabilir olması gerekiyor” der. Peki, anında ne demek? Bir saniye mi, on saniye mi, bir dakika mı? Ve neden? Belki saniyelerin önemli olduğu bir dolandırıcılık tespitidir. Belki de birisi sadece gece yüklemesini beklemekten hoşlanmıyordur. Bunlar çok farklı gereksinimlerdir ve mimar hangisine sahip olduğumuzu öğrenene kadar sormaya devam eder.

Sorgulamaya dayanan gereksinimleri severim: ne kadar, kaç tane, ne kadar hızlı, ne sıklıkla, kimin için ve yapmazsak ne olur? “Hızlı” bir mimari gereksinim değildir. “Müşteri güncellemelerinin yüzde 95’i 30 saniye içinde servis temsilcisine ulaşmalı” buna çok daha yakındır. Artık ödünleşimleri değerlendirebiliriz.

Kısıtlar Cevabı Değiştirir

Bazen mimari teknolojiyle hiç kısıtlı değildir. Parayla, insanla, zamanla, lisanslamayla ya da kurumsal olgunlukla kısıtlıdır.

Teknik olarak mükemmel ama şirketin sahip olmadığı bir operasyon ekibine ihtiyaç duyan bir mimari iyi bir mimari değildir. Sorunu zarif biçimde çözen ama müşterinin almayacağı bir lisans gerektiren bir yetenek de çözüm değildir. Ve mükemmel üç yıllık dönüşüm, sekiz hafta içinde canlıya çıkması gereken bir şirkete yardımcı olmaz.

Bunların hiçbiri bir son tarih yüzünden iyi mimariden vazgeçtiğimiz anlamına gelmez. Neyden ödün verdiğimizi, nedenini ve hangi sonuçları kabul ettiğimizi anladığımız anlamına gelir; ideal olarak da bugünün ödününden yarının mimarisine nasıl geçeceğimizi.

Mimarın Bir “En Uygun” Resmine İhtiyacı Vardır

İşte ilginç bir gerilim. Size çoğu zaman tek bir mükemmel cevap olmadığını söylüyorum, ama aynı zamanda kafanızda en uygun bir çözümün neye benzediğine dair bir resim taşımanızı istiyorum. Bunlar çelişkili değildir. Bir referans noktasına ihtiyacınız var.

Bir veri modeline baktığımda, gereksiz kısıtlar olmadan gereksinimler için en uygun hale getirebilseydim ne inşa edeceğimi bilmek isterim. Sonra gerçek kısıtlar bizi o tasarımdan uzaklaştırdıkça (modelin bir kısmını düzleştiririz, bazı verileri çoğaltırız, bir entegrasyonu erteleriz, geçici bir manuel süreci kabul ederiz) rastgele ödünler vermiyorum. En uygundan hangi yöne ve neden uzaklaştığımı biliyorum. Mimarinin sanatı budur ve bu sezgi pratik ister.

Çizin

Bir ödünleşimi anlamanın en iyi yollarından biri onu çizmektir. Mimari diyagramlar bir sunumun süsü değildir; düşünme araçlarıdır. İki yaklaşım arasında seçim yapıyorsak ikisini de çizin. Veri nerede yaşıyor ve nereye hareket ediyor? Sahibi kim? Sınırlar nerede ve güvenlik nerede uygulanıyor? Bir şey bozulduğunda ne olur ve hacim büyüdükçe ne değişir?

Bir diyagram belirsizliği gün yüzüne çıkarır ve herkese işaret edebileceği aynı resmi verir.

Bunun ne kadar önemli olduğunu bir enerji şirketiyle yaptığım bir projede öğrendim. İnceleme üstüne inceleme, kendimi aynı kavramları yeniden açıklarken ve konuşmayı özgün tasarıma geri çekerken buldum. Bu yüzden toplantıları yürütme biçimimi değiştirdim: her inceleme ekranda veri modeliyle başladı. Her alanı içeren ayrıntılı model değil. Bir özet model: bir hesabın kişileri var, bu kaydın alt kayıtları var, iş burada asılı. Oda çoğunlukla yöneticilerden oluşuyordu ve bu birkaç dakika sürdü.

Her toplantıda aynı insanlar olduğu için diyagram ortak dilimiz oldu. İnsanlar onun adlarını kullanmaya başladı. Tekrarlanan sorular azaldı ve toplantılar çok daha kolaylaştı. Ben buna toplantıyı temellendirmek diyorum: her seferinde gösterilen basit bir diyagram, yapma maliyetinden çok daha değerliydi.

Amaç sanatsal mükemmellik değildir. Bazen mühendisler için ayrıntılı bir diyagram, bazen bir yönetici için beş kutu ve altı ok. Amaç açıklıktır.

Ödünleşimi Açıklayın

İyi bir mimar bunu sırayla ortaya koyar: değerlendirdiğimiz seçenekler bunlar, her birinin bize kazandırdığı bu, her birinin bize maliyeti bu, önerdiğim seçenek bu ve nedeni bu.

Önerinin ödünleşimlerden sonra geldiğine dikkat edin. Mimarinin “Bunu daha önce yaptım, bana güvenin”e dönüşmesini istemem. Deneyim son derece önemlidir; kalıpları daha hızlı tanımanıza ve sorunları daha erken görmenize yardımcı olur. Ama deneyiminiz akıl yürütmenizi geliştirmeli, onun yerini almamalıdır. İşimiz yalnızca mimariyi anlamak değildir. Özellikle son kararı verenler mimar olmadığında, kurumun kararı anlamasına yardımcı olmaktır.

Think Correct. Think Fast.

Her seçeneği analiz etmek için her zaman üç haftanız olmayacak. Bazen üç dakikanız olacak. Bir toplantıda bir gereksinim değişir, biri bilmediğiniz bir kısıttan bahseder ya da bir yönetici “Bunu gelecek yıl Avrupa’da da istersek ne olur?” diye sorar.

Şu ifadeyi kullanırım: Think Correct. Think Fast. (Doğru düşün. Hızlı düşün.) Hız, düşünmeyi atlamaktan gelmez. O an gelmeden önce yeterince düşünmüş olmaktan gelir: kalıpları öğrenmişsinizdir, platformu bilirsiniz, başarısızlıklar görmüşsünüzdür, hangi soruları soracağınızı ve hangi kararların geri alınmasının zor olduğunu bilirsiniz. Kurs boyunca senaryolar üzerinde çalışmamızın nedeni budur. Ne kadar çok karar analiz ederseniz, bir sonrakinin şeklini o kadar hızlı tanırsınız.

Form girişine ihtiyaç duyan bir müşterim vardı. Ama pek çok form vardı ve sorular zamanla değişebiliyordu. Bir anket veri modeline ihtiyaç olduğunu hemen fark ettim; bu, kursun ilerleyen bölümlerinde döneceğimiz bir kalıp. Kalıbı ve çözümü tanıdığım için daha eksiksiz bir veri modeli getirebildim; yalnızca önümüzdekileri değil, henüz gelecek olan gereksinimleri de karşılayan bir model.

Mimari Dengeyle İlgilidir

Veri mimarisinde derinleştikçe size basit bir kural vermekten kaçındığım seçimlerle karşılaşacaksınız. Normalleştirmek mi düzleştirmek mi? Veriyi kopyalamak mı federe etmek mi? Eşzamanlı mı eşzamansız mı? Standart nesne mi özel mi? Arşivlemek mi çevrimiçi tutmak mı?

İlkeler, kalıplar ve sınırlar vardır; bazen de açıkça yanlış cevaplar. Ama çoğu zaman mimarın işi bu sistem, bu iş ve bu an için doğru dengeyi bulmaktır.

En uygunun neye benzediğini bilin. Kısıtları anlayın. Uygulanabilir seçenekleri belirleyin. Ödünleşimleri görünür kılın. Sonra kararı verin.

Bu kararsızlık değildir. Bu mimaridir.

Mimarın Burada Karar Verdikleri

• Hangi seçeneklerin uygulanabilir olduğu ve hangilerinin şimdiden yanlış olduğu ya da bir yıl içinde kötüleşeceği.
• Her uygulanabilir seçeneğin sorgulamaya dayanan gereksinimlere göre ölçüldüğünde ne kazandırdığı ve neden vazgeçtiği.
• Hangi kısıtların gerçek, hangilerinin yalnızca tercih olduğu.
• Ödünleşimleri ortaya koyduktan sonra hangi seçeneğin önerileceği ve nasıl açıklanacağı.