Bir Mimar Gibi Düşünmek
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 1.‘si. Her modül kendi başına okunabilir. Önceki: bölüme genel bakış · Sonraki: Veri Modeli İskelettir
Bu modülün yanıtladığı soru: İnşa etmek ile mimari tasarlamak arasındaki fark nedir ve bir mimar gerçekte ne yapar?
Kariyerimin büyük bölümünde bir inşa eden oldum.
Geliştirici olarak başladım. Salesforce’a geçmeden önce Java ve .NET ile çalıştım; yıllarca sistemler tasarladım, kod yazdım, platformları entegre ettim, mimarlara ders verdim ve mimarileri inceledim.
Ama bu yolda öğrendiğim en önemli derslerden biri şu oldu: harika bir inşa eden olmak ile harika bir mimar olmak her zaman aynı şey değildir.
İnşa eden şunu sorar:
Bunu nasıl inşa ederim?
Bir mimar ise farklı sorular sormak zorundadır:
Bunu inşa etmeli miyiz?
Neden bu şekilde inşa ediyoruz?
Alternatifler neler?
Bu büyüdüğünde ne olur?
Çöktüğünde ne olur?
Ve bugün verdiğimiz hangi karar için üç yıl sonra keşke daha çok düşünseydik diyeceğiz?
Randevularla çalışan bir perakende işletmesinin projesinde bulunduğumu hatırlıyorum. Sordum: mağaza başına günde kaç randevu var? Sonra: kaç mağazanız var? Haftada kaç gün açıksınız? Çabucak fark ettim ki yalnızca ilk yılda milyonlarca randevumuz olacaktı. Bir mimarın projenin başında sorduğu sorular bunlardır.
Bu kursun asıl konusu bu düşünce değişikliği.
Planı Elinde Tutan Kişi
Bölüm başlığı “Planı Elinde Tutan Kişi ”Mimarlara ders verirken bu benzetmeyi defalarca kullandım.
Bir inşaat alanı düşünün. Beton döken, elektrik tesisatı çeken, sıhhi tesisat döşeyen, duvar iskeleti kuran ve onlarca başka uzmanlık işi yapan insanlar var. Hepsinin işinde çok iyi olması gerekir.
Ama birinin de planı elinde tutması gerekir.
O kişinin bütün bu parçaların nasıl bir araya geldiğini anlaması gerekir. Projenin bir bölümünde olan bir şeyin başka bir yerde ne zaman sorun yarattığını fark etmesi gerekir.
İşte mimari budur.
Teknolojide bazen mimarın sadece en çok bilen kişi olduğunu sanma hatasına düşeriz. Aslında öyle değil. Platformu bilmek önemlidir; teknik derinliğe ihtiyacınız var. Ama mimari bir bilgi yarışması değildir.
Mimarın işi, bazen eksik bilgi ve birbiriyle çatışan gereksinimlerle iyi kararlar vermek ve bu kararların sonuçlarını anlamaktır.
Bu çok farklı bir beceridir.
Gereksinimi Olduğu Gibi Almayın
Bölüm başlığı “Gereksinimi Olduğu Gibi Almayın ”Mimarların geliştirmesini istediğim ilk alışkanlıklardan biri basittir:
Neden diye sorun.
Biri size şunu söyler:
Bir nesneye daha ihtiyacımız var.
Neden?
Bu alanın Hesap’a kopyalanması gerekiyor.
Neden?
Bu verilerin hepsinin Salesforce’ta saklanması gerekiyor.
Neden?
Bu zorluk çıkarmak demek değildir. Önerilen çözümü hemen uygulamak yerine asıl iş gereksinimini anlamak demektir.
Bir gereksinim çoğu zaman bir tasarım kılığında gelir.
“Yeni bir özel nesneye ihtiyacımız var” mutlaka bir gereksinim değildir. Gereksinim aslında “bu bilgiyi ayrı olarak izlememiz gerekiyor” olabilir. Bunlar aynı şey değildir.
Gerçek gereksinimi anladıktan sonra alternatifleri keşfetmeye başlayabilirsiniz. Belki yeni bir nesne tam da doğru cevaptır. Belki bilgi zaten var olan bir yere aittir. Belki Salesforce bu verinin sahibi olmamalıdır.
Mimar, işin neye ihtiyaç duyduğunu onu karşılamanın önerilen bir yolundan ayırmak zorundadır.
Bir satış uygulaması üzerinde çalışıyorduk ve müşterinin her biri bir onaylayan ve bir tarihten oluşan birden fazla onayı vardı. İlk talepleri Fırsat’a, her biri tarihli olmak üzere Onaylayan 2 ve Onaylayan 3 alanlarının eklenmesiydi. Biraz derine indiğimizde ikiden ya da üçten fazla onay olabileceğini anladık. Bu yüzden onayları bir alt nesneye taşıdık. Talep daha fazla alandı; gereksinim ise kaç tane çıkarsa çıksın her onayı izlemekti.
Gereksinimin Ötesini Düşünmek
Bölüm başlığı “Gereksinimin Ötesini Düşünmek ”Neden diye sormaktan iki alışkanlık doğar; her birine bu bölümün ilerleyen kısmında ayrı bir modül ayrılıyor.
Genellikle birden fazla cevap vardır. Salesforce bize bir sorunu çözmenin pek çok yolunu sunar ve bunların bazıları neredeyse anında yanlıştır. İşe yarayanlar arasında seçim yapmak ödünleşim sanatıdır (modül 4).
Ve size verilen gereksinimler sahip olduğunuz tüm gereksinimler değildir. Kimse “gece yükleme işlemi yalnızca yarı yarıya başarılı olduğunda da bunun çalıştığından emin ol” demez, ama bu yine de bir gereksinimdir. Her tasarıma üç mercekten bakarım: bugün için inşa edin, yarın için planlayın, başarısızlık için planlayın (modül 5).
Bir bina tasarlatmak için mimar tutan birini düşünün. Yangın alarmı ya da yağmurlama sistemi istemezler, binanın depremde ayakta kalmasını da talep etmezler. Bunu sormadan, işin bir parçası olarak beklerler. Bizim dünyamız da aynı şekilde işler. Kimse zarif hata yönetimi, günlükler ya da bir şey bozulduğunda kurtarma yolu istemez. Bu sistemlerden hangilerinin tasarıma ait olduğunu bilmek ve onları tasarıma koymak mimara düşer.
Gerekçenizi Görünür Kılın
Bölüm başlığı “Gerekçenizi Görünür Kılın ”Bir mimar bir odaya girip öylece “Bunu yapıyoruz” diye ilan etmemelidir.
İşiniz aynı zamanda nedenini açıklamaktır. Paydaşların değerlendirdiğimiz alternatifleri ve işin içindeki ödünleşimleri anlamasını isterim. Bu, bir yöneticiye 40 sayfalık bir tasarım belgesi vermek demek değildir. Aynı mimariyi bir geliştiriciye, iş birimine ve bir yöneticiye açıklayabilmek demektir: aynı karar hakkında farklı konuşmalar.
Bunu yapmanın yolu, inşaat alanında planı elinde tutan kişi gibi net planlar ve talimatlardır. Bir Veri Mimarı için bu planların en önemlilerinden biri veri modelidir.
Bir kararın neden verildiğini kimse anlamıyorsa, birinin onu er geç geri alma ihtimali yüksektir. Üstelik bunun için gayet makul gerekçeleri de olabilir, çünkü asıl kararı kimse hiç açıklamamıştır.
Mimarın Her Şeyi Kendisinin İnşa Etmesi Gerekmez
Bölüm başlığı “Mimarın Her Şeyi Kendisinin İnşa Etmesi Gerekmez ”Özellikle mimariye geliştirmeden gelenler için zorlayıcı olabilecek bir geçiş daha var.
Her şeyi bizzat kendiniz inşa etmek zorunda değilsiniz.
Hâlâ işlerin çok teknik bir düzeyde nasıl yürüdüğünü anlamayı seviyorum ve bu temel önemlidir. Ama bir mimar olarak sorumluluğunuz kendi uygulamanızdan daha büyük hale gelir. Her şeyi kendiniz inşa etmek zorunda değilsiniz; onu inşa eden insanlara doğru yönü ve doğru parametreleri vermeyi bilmeniz gerekir. Bu da onların işine yol gösterecek, önerilen bir uygulamanın ne zaman mimari bir sorun yarattığını fark edecek ve ayrıntılarla büyük resim arasında gidip gelecek kadar şey anlamak demektir.
Bazen bu bir sorguya, bir API’ye ya da bir veri modeline derinlemesine dalmak demektir.
Bazen de bir adım geri çekilip bunların herhangi birini yapmamız gerekip gerekmediğini sormak demektir.
Ve inşa eden giderek yalnızca insanlar olmuyor. Yapay zekâyla mimar, nesneleri, kodu ve ekranları üreten araçla doğrudan çalışıyor olabilir. O zaman yön, parametreler ve yönergeler yapay zekâya gider ve bunları iyi vermek giderek daha fazla mimarın sorumluluğu haline gelir. Buna 7. modülde döneceğiz.
Bu, inşa edenden mimara giden yolculuğun bir parçasıdır.
İşiniz Karar Vermektir
Bölüm başlığı “İşiniz Karar Vermektir ”Sonuçta mimari kararlarla ilgilidir.
Bazı kararları değiştirmek kolaydır. Bazılarını değil.
Bir sayfa düzeni değiştirilebilir. Bir etiket yeniden adlandırılabilir.
Ama temel veri modelini yanlış seçerseniz, onlarca sistemin bağımlı hale geldiği tanımlayıcılar yayımlarsanız ya da kritik verinin ana kopyasını yanlış yere koyarsanız, fikrinizi değiştirmek çok daha pahalı hale gelir.
Bunlar mimari kararlardır. Ve bu kursun yoğunlaştığı kararlar tam olarak bunlardır.
Bir Veri Mimarı olarak bilginin nasıl yapılandırıldığı, nerede yaşadığı, nasıl büyüdüğü, nasıl hareket ettiği, kimin erişebildiği ve kurumun geri kalanının onu nasıl anladığı hakkında kararlar vereceksiniz.
Teknoloji önemlidir.
Ama her Salesforce özelliğini bilmek hedef değildir.
Hedef, hangi aracı kullanacağınızı, ne zaman kullanacağınızı, neden vazgeçtiğinizi ve sonra ne olacağını bilecek muhakemeyi geliştirmektir.
Bir mimar gibi düşünmek budur.
Ve artık bir Veri Mimarı gibi düşünmeye başlayabiliriz.
Mimarın Burada Karar Verdikleri
Bölüm başlığı “Mimarın Burada Karar Verdikleri ”- Bir talebin gerçek bir gereksinim mi, yoksa onun için önerilen bir tasarım mı olduğu.
- Herhangi bir şey inşa edilmeden önce hangi soruların sorulacağı: yapmalı mıyız, neden bu şekilde, başka ne yapabiliriz, büyüdüğünde ya da çöktüğünde ne olur.
- Hangi kararların mimara, hangilerinin inşa edenlere ait olduğu; ve inşa edenlere, ister insan ister yapay zekâ olsun, hangi yönün ve parametrelerin verileceği.
- Bir kararın, bir geliştiricinin, iş biriminin ve bir yöneticinin her birinin anlayacağı şekilde nasıl açıklanacağı.