Birlikte çalıştığım her emeklilik şirketinin, 2019'dan beri kimsenin dokunmadığı bir SharePoint klasörüne veya Confluence sayfasına tıkıştırılmış aynı çıktısı var: orijinal alan eşleme dokümanı. BES raporlama pipeline'ı ilk kurulduğunda yazılmış, muhtemelen iki hafta boyunca bir geliştiriciyle oturup regülatif şemayı dahili kolon adlarına çeviren bir iş analisti tarafından. katki_payi_net, NetContribution'a eşleniyor. giris_aidati, EntryFee'ye eşleniyor. İmzalanmış, commit'lenmiş, unutulmuş.
Sonra beş yıl geçer. Ürün ekibi üç yeni plan türü lanse eder. Finans, otomatik katılım katkılarındaki mutabakat sorununu düzeltmek için ETL'yi iki kez yamalar. Regülasyonu netleştiren genelge yayımlandığı için birisi vergi stopajı mantığını değiştirir. Kıdemsiz bir geliştirici staging katmanını refactor eder ve okunabilirlik için iki kolonu yeniden adlandırır.
Bunların hiçbiri eşleme dokümanına geri yansımaz.
Tanım, koddan daha hızlı çürür
Kodun testleri var. Kodun git blame'i var. Kodun bozulduğunda çığlık atan bir production sistemi var. Tanımların bunların hiçbiri yok. SEDDK veya EGM bir veri kalitesi sorgusu gönderdiğinde — ki çoğu ekibin herkese açık olarak itiraf ettiğinden daha sık gönderirler — soru nadiren "bu sayı neden yanlış" olur. Soru şudur: "bu alan sunumunuzda tam olarak neyi temsil ediyor."
Ve dürüst cevap genellikle şunun bir varyasyonudur:
- "
fn_calculate_net_contributionfonksiyonundan her ne çıkıyorsa o." - "O kısmı Ahmet yazmıştı, spec hâlâ onda mı bir bakayım."
- "Devlet katkı payını hariç tuttuğunu düşünüyoruz ama SQL'i takip etmemiz gerekir."
Bunların hiçbiri bir düzenleyicinin kabul edeceği cevaplar değil. Bir tanım, bir kaynak ve tanımın denetledikleri raporlama dönemi boyunca tutarlı biçimde uygulandığına dair kanıt istiyorlar.
Kayma aslında nerede oluyor
İncelediğim BES pipeline'larında kayma birkaç öngörülebilir yerde yoğunlaşıyor:
Katkı alanları. "Net katkı", brüt katkı eksi giriş aidatı olarak başladı. Sonra devlet katkı payı ayrıştırıldı. Sonra otomatik katılım cayma iade işlemleri netleştirildi. Her değişiklik o an için doğruydu. Hiçbiri alan tanımını güncellemedi.
Fon dağılım alanları. Yeni fon türleri eklendiğinde, dağılım yüzdesi alanları aynı adları korudu ama hesaplama bağlamına göre belirli fon kategorilerini dahil veya hariç tutmaya başladı. Regülatif şema "hisse senedi fonu dağılımı" diyor. Sizin pipeline'ınızda bu kavramın hafifçe farklı üç versiyonu var; biri SEDDK sunumunda, diğer ikisi dahili raporlarda kullanılıyor.
Tarih alanları. "Katkı tarihi" ya katılımcının ödemeyi yaptığı tarih, ya paranın emeklilik hesabına ulaştığı tarih, ya birimlerin tahsis edildiği tarih ya da vergi raporlamasında kullanılan valör tarihidir. Dördü de mevcut. Dördü de kendi bağlamında doğru. Sadece biri regülatif sunuma aittir ve orijinal eşlemenin hangisini seçtiğini kimse hatırlamıyor.
Durum alanları. Katılımcı durum kodları, ürün kataloğu büyüdükçe genişletiliyor. Düzenleyicinin enumerasyonu sabittir. Sizin dahili enumerasyonunuz değildir. Bunların arasında çeviri yapan eşleme tablosu ya bir view'a gömülü hardcoded bir CASE ifadesi ya da birinin masaüstündeki bir Excel dosyasıdır.
Standart çözümler neden işe yaramıyor
Olağan yanıt "veri kataloğuna ihtiyacımız var" veya "bir yönetişim aracı uygulayalım" olur. Türk finans kurumlarında bu girişimlerin üç tanesinin nasıl yürüdüğünü izledim. İkisi terk edildi. Biri, değişiklik yapmadan önce kimsenin başvurmadığı, çoğunlukla boş bir Collibra instance'ı olarak hayatta kalıyor.
Sebep basit: insanların alanları sonradan manuel olarak belgelemesini gerektiren araçlar, teslimat baskısına karşı her zaman kaybedecektir. Ürün ekibinin yeni plan türünü çeyrek sonuna kadar canlıya alması gerekiyor. Kimse veri sözlüğü güncellenmedi diye yayını bekletmeyecek.
Çözüm prosedürel değil, yapısal olmak zorunda.
Regülatif inceleme altında gerçekten ayakta kalan şey
Pratikte işe yaradığını gördüğüm birkaç örüntü:
Tanımlar, dönüşüm koduyla aynı repo'da yaşar. NetContribution bir dbt modelinde veya bir stored procedure'de hesaplanıyorsa, tanım — Türkçe olarak, düzenleyicinin kullandığı tam dilde — kodun yanındaki bir YAML dosyasında veya yorum bloğunda durur. Hesaplamadaki herhangi bir değişiklik, aynı pull request içinde tanımın da değiştirilmesini gerektirir. Reviewer'lar, tanıma dokunmadan mantığı değiştiren PR'ları reddeder.
Regülatif şema, birinci sınıf bir çıktı olarak versiyon kontrolündedir. SEDDK ve EGM şema güncellemeleri yayınlar. Bu güncellemeler bir repo'ya girer, diff'i alınır ve diff, değişen bir regülatif alana eşlenen her alanın gözden geçirilmesini tetikler. Bu sıkıcı bir iştir. Aynı zamanda bir regülatif netleştirmenin mevcut eşlemenizi sessizce geçersiz kıldığı anı yakalamanın tek yoludur.
Sunum snapshot'ları, yalnızca veriyi değil tanımı da içerir. Her aylık veya çeyreklik sunum, o anda geçerli olan alan tanımlarıyla birlikte arşivlenir. Düzenleyici on sekiz ay önceki bir sunumu sorduğunda, sunum oluşturulduğunda canlı olan veri ve tanım sözlüğünü sunarsınız. Düzenleyicilerin kanıt olarak fiilen kabul ettiği çıktı budur.
Mutabakat, yalnızca değer üzerinden değil tanım üzerinden çalışır. "Net katkı" brüt eksi giriş aidatı eksi devlet katkısı olarak tanımlanıyorsa, sunulan değeri ayrıştıran ve bileşenlerin doğru toplandığını doğrulayan bir test vardır. Biri hesaplamayı tanımı güncellemeden değiştirdiğinde, test başarısız olur. Pipeline yayınlanmaz.
Rahatsız edici kısım
Bu işin çoğu göz alıcı değil. Özellik teslim etmiyor. Herhangi bir dashboard'u hareket ettirmiyor. İş gerekçesi tam olarak bir kez netleşir — bir düzenleyicinin resmi bir veri kalitesi sorgusu gönderdiği ve bir alanın üç yıl önce ne anlama geldiğini git geçmişinden ve Slack mesajlarından yeniden inşa etmek zorunda kaldığınız ilk sefer.
O noktada bir veri sorununu çözmüyorsunuz. Bir regülatif ilişkiyi yönetiyorsunuz ve verdiğiniz cevap, önümüzdeki beş yıl boyunca ne kadar incelemeye tabi tutulacağınızı şekillendiriyor.
Bunu iyi yöneten ekipler, daha önceki bir noktada tanımın ürünün bir parçası olduğuna karar verdiler. Yönetmeyenler ise sorgu geldikten sonra beni çağıran ekipler.