Her mühendislik ekibi teknik borcu bilir. JIRA'da takip edilir, sprint retrospektiflerinde tartışılır, zaman zaman özel temizlik sprintlerinde giderilir. Liderlik bunu — en azından soyut olarak — anlıyor. Kavram ana akım organizasyon söylemine girmiş durumda.
Veri borcu henüz girmedi. Ve düzenlenmiş finansal ortamlarda bu ciddi bir sorun.
Veri Borcu Gerçekte Nedir
Veri borcu, verinin nasıl tanımlandığı, sahiplenildiği, depolandığı ve yönetildiğine dair ertelenmiş kararların birikimli maliyetidir. Somut biçimlerde kendini gösterir:
Sistemler arasında tutarsız tanımlar. "Aktif müşteri" CRM'de, aktüeryal modelde ve düzenleyici raporlama pipeline'ında farklı anlama geliyor. Kimse bu farklılaşmaya bilinçli bir karar vermedi. Yıllar içinde, her sistem bağımsız evrilirken kendiliğinden oldu.
Belgesiz dönüşümler. Raporlama veritabanındaki net_prim alanı, kaynak sistemdeki net_prim ile aynı değil. İngestion ile sunum arasında bir yerde bir hesaplama gerçekleşti. Bunu kim yazdı, ne zaman, neden — bu bilgi artık mevcut değil. Yapanlar çoktan ayrıldı.
Sahipsiz veri varlıkları. Doldurulan ama hiç sorgulanmayan tablolar. Her gece çalışan ve on sekiz aydır erişilmemiş veri yükleyen ETL işleri. Güvenle kaldırılabilirler mi? Kimse bilmiyor. Zor yoldan öğrenmek isteyen de çıkmıyor.
Yalnızca insanların kafasında var olan kalite kuralları. Belirli bir eski sistemden gelen veriye güvenilmeden önce düzeltme faktörü uygulanması gerektiğini bilen kıdemli analist. O analist ayrıldığında, bilgi de gidiyor.
Finansal Hizmetlerde Neden Bu Kadar Hızlı Birikir
Düzenleyici ortam, hızlı inşa etme baskısı yaratır. FATCA geliyor, bir pipeline kuruyorsunuz. CRS ekleniyor, genişletiyorsunuz. HAYMER emekliliğe özgü gereksinimler getiriyor, mevcut pipeline'ı yama yapıyorsunuz. Her ekleme, deadline baskısı altında, minimum dokümantasyonla, kim varsa onun tarafından yapılıyor.
Zamanla raporlama altyapısı kimsenin tam olarak anlamadığı bir şeye dönüşüyor. Ekipteki her kişi kendi parçasını anlıyor. Tüm resmi gören yok. Ve bir denetçi gönderilen bir rakamı açıklamanızı istediğinde tam resim tam da onlara lazım olan şey.
Bu örüntüyü farklı büyüklüklerdeki organizasyonlarda defalarca gördüm. Compliance submission'lar çoğunlukla doğru. Yapanlar her zaman yetkin. Ama bu submission'ları açıklama, yeniden üretme ve denetleme kapasitesi her yıl geriliyor; çünkü altındaki veri altyapısı hiç giderilmemiş borç taşıyor.
Görünür Hale Geldiği An
Veri borcu görünmezdir — ta ki olmadığı ana kadar. Tetikleyiciler tahmin edilebilir:
Bir düzenleyici, üç yıl önceki gönderilen bir rakamın geçmişe dönük açıklamasını istiyor. Yeni bir sistem implementasyonu, herkesin aynı alan olduğunu varsaydığı şey için iki kaynak sistemin farklı değerler ürettiğini ortaya çıkarıyor. Bir yönetici, hiç uzlaştırılmamış üç sistemden veri birleştirmeyi gerektiren bir soru soruyor.
O noktada dokümantasyon sorunu gibi görünen şey kendini bir mimari sorun olarak ortaya koyuyor. Soruyu yanıtlamak için gereken çalışma saatler değil — haftalar.
Kabul Etmek ile Adres Etmek Arasındaki Fark
Çoğu veri ekibi veri borcu olduğunu biliyor. Kabul etmek zor değil. Zor olan, ağrı gelmeden önce bununla başa çıkma organizasyonel gerekçesini ortaya koymak.
Genellikle işe yarayan argüman: veri borcunu operasyonel kapasite açısından çerçevelemek. Kıdemli bir analistin sistemler arasındaki rakamları elle uzlaştırmak için harcadığı her saat, analize ayrılmayan bir saattir. Bir veri mühendisliği ekibinin belgelenmemiş pipeline davranışlarını gidermek için harcadığı her sprint, yeni kapasite inşa etmeye ayrılmayan bir sprinttir. Borcun yalnızca teorik bir gelecek riski değil, süregelen bir operasyonel maliyeti var.
Bu maliyeti — kabaca bile olsa — sayıya dökebildiğinizde, yatırım konuşması farklı bir boyut kazanıyor.
Teknik borç, sonunda sistem kararsızlığı veya geliştirici kaybı yoluyla hesaplaşmayı zorlar. Veri borcu ise denetim bulgularıyla, düzenleyici sorularla ve yöneticilerin rakamlara olan güvenini yitirmesiyle. İkincisinden toparlanmak daha zor. Erken yapılan yatırım, baskı altında yapılan iyileştirmeden çok daha ucuz.