Bir yazılım projesinin ilk günlerinde alınan kararlar çoğu zaman masum görünür: Veritabanını şimdilik tek sunucuda tutalım, kullanıcı kimliğini e-posta adresiyle eşleştirelim, modülleri hızlı ilerlemek için aynı kod tabanında toplayalım. Ekip küçüktür, müşteri acele eder, bütçe dardır. Herkes “sonra düzeltiriz” der. Fakat bilişim dünyasında bazı “sonralar”, yıllar sonra milyonlarca kullanıcının, yüzlerce geliştiricinin ve kritik iş süreçlerinin omzuna çöken birer mimari gölgeye dönüşür.
Geri dönüşsüz karar, teknik olarak asla değiştirilemeyecek karar demek değildir. Çoğu sistem yeniden yazılabilir, veri taşınabilir, servisler ayrıştırılabilir. Ancak değişimin maliyeti zamanla öyle büyür ki karar pratikte geri dönüşsüz hale gelir. Bir apartmanın temelini değiştirmek mümkündür; fakat apartman doluyken, çevresinde trafik akarken ve kiracılar her gün yaşamaya devam etmek zorundayken bu iş yalnızca mühendislik problemi olmaktan çıkar. Yazılım mimarisi de böyledir: Kodun altında çalışan iş kuralları, kullanıcı alışkanlıkları, entegrasyonlar ve kurum hafızası vardır.
Küçük Kestirmeler, Büyük Kilitler
En klasik örnek veritabanı seçimidir. Başlangıçta ilişkisel bir model, sipariş ve müşteri kayıtları için son derece mantıklıdır. Ancak sistem zamanla sosyal etkileşim, gerçek zamanlı analiz, belge depolama veya devasa olay akışları üretmeye başladığında ilk model zorlanabilir. Sorun, seçimin “yanlış” olması değildir. Sorun, ilk tercihin bütün uygulamanın varsayımlarına sızmasıdır. Sorgular, raporlar, yetkilendirme kuralları, yedekleme stratejileri ve ekip yetkinlikleri o seçime göre şekillenir. Böylece veritabanı bir araç olmaktan çıkar, sistemin görünmez anayasasına dönüşür.
Monolit mimarisi de benzer bir hikâye anlatır. Erken aşamada monolit çoğu zaman doğru karardır: Dağıtımı basittir, hata ayıklaması daha kolaydır, ekip tek bir bağlamda çalışır. Ne var ki ürün büyüdüğünde küçük bir ödeme değişikliği ile bildirim sisteminin aynı sürüm paketi içinde yaşaması, her yayınlamayı yüksek riskli hale getirebilir. Bu noktada mikroservisler sihirli değnek değildir. Monoliti plansız biçimde parçalara ayırmak, tek bir büyük düğüm yerine yüzlerce küçük düğüm üretmek anlamına gelir. Asıl mesele teknoloji modası değil, bağımlılıkların bilinçli yönetimidir.
Teknik Borç Faizle Çalışır
Teknik borç benzetmesi sık kullanılır, çünkü acı verici biçimde doğrudur. Hız kazanmak için alınan kısa vadeli kararların gelecekte bakım maliyeti vardır. Fakat bu borcun faizi yalnızca kod karmaşıklığı değildir. Yeni geliştiricilerin sistemi anlaması uzar, test yazmak zorlaşır, güvenlik açıkları daha geç fark edilir, ürün fikirleri “altyapı izin verirse” şartına bağlanır. Bir noktadan sonra şirketin stratejisini pazar değil, geçmişte yazılmış kod belirlemeye başlar. İşte mimari kararların en büyük etkisi burada ortaya çıkar: Gelecekte hangi fikirlerin uygulanabilir olduğunu sessizce seçerler.
Bu nedenle iyi mimari, geleceği kusursuz tahmin etme sanatı değildir. Böyle bir tahmin zaten mümkün değildir. İyi mimari; değişmesi muhtemel alanları izole etmek, veri sahipliğini açık tanımlamak, gözlemlenebilirlik kurmak ve geri alma maliyetini erken hesaplamaktır. Bir karar kayda geçirilmelidir: Neyi seçtik, hangi alternatifi neden elemedik, hangi varsayımlara güveniyoruz ve hangi işaretler geldiğinde bu kararı yeniden değerlendireceğiz? Mimari karar kayıtları, gelecekteki ekiplere bırakılmış küçük ama çok değerli zaman kapsülleridir.
En sağlıklı yaklaşım, her bileşeni esnek yapmaya çalışmak değildir; bu da pahalı ve karmaşık bir yanılsamadır. Bunun yerine geri dönüşü zor alanları erkenden tanımak gerekir: kimlik yönetimi, veri modeli, güvenlik sınırları, dış entegrasyon sözleşmeleri ve dağıtım altyapısı. Bu alanlarda yavaş düşünmek, diğer alanlarda hızlı denemeler yapmayı mümkün kılar. Yazılımda özgürlük, hiç bağ kurmamakla değil, hangi bağların bir gün çözülmesinin pahalı olacağını bilmekle başlar.