Birlikte çalıştığım her BES operatörü, yeni kanal onboarding'ini bir proje yönetimi egzersizi olarak ele alır. Kickoff toplantısı, SFTP kimlik bilgileri, örnek dosyalar, UAT, canlıya alma. Gantt şeması temiz görünür. Sonra yeni bankadan, aracı kurumdan veya işyeri platformundan ilk gerçek production dosyası gelir ve ingestion katmanınızda bir yerlerde, mevcut ekipten kimsenin dört yıldır görmediği bir exception fırlatılır.
Dosya teknik olarak geçerlidir. Parse edilir. Şema uyuşur. Ama yine de üç downstream job'u bozar, bir mutabakat raporunu bozar ve bir sonraki katkı payı döngüsüne sızacak manuel müdahaleyi zorunlu kılar.
Bu, karşı taraf onboarding sorunudur ve teknik bir entegrasyon sorunu değildir. Bu bir sözleşme arkeolojisi sorunudur.
Kimsenin Yazıya Dökmediği Örtük Sözleşmeler
BES platformunuz inşa edildiğinde iki veya üç dağıtım kanalı vardı. Ingestion katmanı, bu kanalların davranışını kafasında tutabilen insanlar tarafından yazıldı. Zamanla, bu davranışlar hiçbir zaman dokümantasyona geçmeyen varsayımlara dönüştü:
- Banka kanalı katkı paylarını her zaman T+1'de gönderir, hiçbir zaman birden fazla güne yayılmış toplu şekilde göndermez.
- Aracı kurum kanalı her zaman müşterinin TCKN'sini primary key olarak kullanır, hiçbir zaman poliçe numarasını kullanmaz.
- İşyeri kanalı her zaman işveren başına bir dosya gönderir, hiçbir zaman birden fazla işvereni birleştiren tek bir dosya göndermez.
- İşveren katkıları ve çalışan katkıları her zaman ayrı line item'lardadır, hiçbir zaman netleştirilmez.
- Değerleme tarihi her zaman dosya tarihine eşittir, tek istisna herkesin hatırladığı legacy bankadır çünkü onun için hardcoded bir istisna vardır ve orada dosya tarihi eksi bir kullanılır.
Bunların hiçbiri yazılı değildir. Kodda if channel_id == 'X' dallanmaları olarak, 2019'dan beri dokunulmamış stored procedure'lerde ve altı yıldır günlük mutabakat yapan iki operasyon analistinin kas hafızasında yaşarlar.
Sonra yeni bir işyeri platformu gelir. Katkı paylarını haftalık olarak, beş iş gününe yayılmış toplu şekilde, işveren ve çalışan tutarları tek bir satırda netleştirilmiş olarak, aylık güncellenen ayrı bir referans dosyası üzerinden TCKN'ye eşlenen dahili bir çalışan ID'si kullanarak gönderirler.
Bu seçimlerin her biri SPK format spesifikasyonu altında yasaldır. Her biri pipeline'ınızın varsaydığı bir şeyi ihlal eder.
Çığ Etkisi
Sözleşme çalışmasını önce yapmadan yeni kanalı absorbe etmeye çalıştığınızda gerçekte ne olduğu şu:
Production'ın 1. Günü. Dosya ingest edilir. Line item'lar staging tablosuna yüklenir. Kanala özgü handler bunları işler. Kimse yanlış bir şey fark etmez çünkü dosya validation'dan geçmiştir.
2. Gün. Fon muhasebesi tarafına karşı çalışan mutabakat job'u bir tutarsızlık işaretler. Netleştirilmiş tutarlar, fon tarafının beklediği ayrıma uymaz. Bir analist, önceki aydan bir oran kullanarak bunları manuel olarak ayırır. Kırk dakika sürer.
5. Gün. Haftalık batch gelir. Şimdi beş günün dördü için T-tarihi mantığı yanlıştır. Hafta ortasındaki katkılar için birim fiyatlar yanlış uygulanır. Hata küçüktür — katılımcı başına birkaç kuruş — ama sistematiktir ve yeni platformdaki her katılımcıyı etkiler.
12. Gün. Biri aylık işveren katkı raporunu çalıştırmaya kalkar. Rapor işverene göre gruplandırır, ancak bu platformun dosyasında raporun okumadığı bir alanda gömülü olarak katılımcı başına bir işveren vardır. Katkıların yarısı null işveren altında görünür.
30. Gün. SPK tarafından zorunlu kılınan katılımcı bildirimleri gönderilir. Yeni platformdaki katılımcılar, işverenlerinin söylediğiyle eşleşmeyen katkı tarihleri görürler. Şikayetler başlar. Çağrı merkezi eskaleyi yükseltir. Şimdi uyum devrededir.
Bu başarısızlıkların hiçbiri ingestion katmanında gerçekleşmedi. Downstream'de, ingestion katmanının hiçbir zaman zorlamak zorunda kalmadığı için zorlamadığı varsayımlar altında veri tüketen sistemlerde gerçekleşti.
Konfigürasyon Framework'leri Bunu Neden Çözmez
Standart yanıt, bir kanal konfigürasyon framework'ü inşa etmektir. Alan eşlemelerini, tarih mantığını, netleştirme kurallarını, anahtar çözümlemesini parametreleştirin. Onboarding'i bir kod egzersizi yerine bir config egzersizi haline getirin.
Bu yardımcı olur, ama gerçek sorunu çözmez. Sorun şu ki, downstream sistemleriniz formal bir sözleşmeye karşı değil, belirli kanalların davranışına karşı yazılmıştır. Ingestion sınırında bir konfigürasyon framework'ü, mutabakat motorunuza, raporlama katmanınıza, bildirim generator'ünüze ve uyum job'larınıza alanların ne anlama geldiğine ve hangi invariantların geçerli olduğuna dair paylaşılan bir anlayış geriye dönük olarak vermez.
Input'u istediğiniz kadar normalize edebilirsiniz. Downstream kod contribution_date = file_date şeklinde örtük bir varsayım içeriyorsa, hiçbir miktarda ingestion konfigürasyonu, varsayımın artık bir kanal için yanlış ve diğer tümü için doğru olduğu gerçeğini düzeltmeyecektir.
Gerçekten Yapılması Gereken
Yeni bir kanalı doğru şekilde onboard etmek, önce arkeolojiyi yapmayı gerektirir. Bu göz alıcı olmayan bir iştir ve proje planına asla sığmaz.
- Örtük varsayımları sıralayın. Katkı verisi tüketen her downstream job'u okuyun. Tarih semantiği, anahtar semantiği, aggregation semantiği ve zamanlama semantiği hakkında neyi varsaydığını yazın. Bu, teknik entegrasyondan daha uzun sürecektir.
- Her varsayımı sınıflandırın. Bu gerçek bir iş invariant'ı mı, yoksa tarihin bir kazası mı? Legacy banka için T-tarihi kuralı bir kazadır. İşveren ve çalışan katkılarının ayrı ayrı tanımlanabilir olması gereği gerçek bir invariant'tır çünkü vergi muamelesi farklıdır.
- Invariantları açık sözleşmelere yükseltin. Onları örtük kod davranışından çıkarıp ingestion ve downstream arasındaki sınırda doğrulanan şema kısıtlamalarına taşıyın. Bir kanal invariant'ı karşılayamıyorsa, ingestion katmanı bunu karşılayabilir hale getirene kadar dönüştürmeli veya dosyayı reddetmelidir.
- Kazaları çeviri katmanlarıyla ele alın. Tarihsel kaza olan varsayımlar için, downstream kodun tutarlı bir dünya görmesi için kanal seviyesinde çeviri inşa edin.
- Downstream'i test edin, upstream'i değil. Yeni bir kanal için UAT "dosya yükleniyor" ile durmamalıdır. Yeni kanaldan sentetik veriler üzerinde mutabakat, raporlama ve bildirim üretimi dahil tam bir ay sonu döngüsü çalıştırmalıdır.
Gerçek Maliyet
Bu işin nadiren yapılmasının nedeni, scope creep gibi görünmesidir. İş birimi yeni bir dağıtım ortağını onboard etmeyi istedi. Siz, o ortakla hiçbir ilgisi olmayan sistemleri denetlemeyi ve refactor etmeyi öneriyorsunuz. Her steering committee geri itecektir.
Alternatif, maliyeti operasyonel yük, manuel mutabakat ve uyum riski olarak ödemeye devam etmektir. Her yeni kanal yığına başka bir örtük istisna katmanı ekler ve yığın, arkeolojik çalışmanın maliyetinin yirmi katına mal olacak bir platform yeniden yazımını sonunda zorlayan şeydir.
Bir BES pipeline'ı, genel anlamda bir data pipeline değildir. Düzenleyici dişleri olan bir uzlaştırma sistemidir. İçine gömülü varsayımlar yük taşıyıcıdır. Bunları su yüzüne çıkarmadan yeni bir karşı tarafı onboard etmek bir kısa yol değildir — katılımcı şikayetleri ve SPK sorgulamaları biçiminde bileşik faiz uygulayan bir kredi verenden borç almaktır.
Onboarding projesi, dosya yüklendiğinde bitmiş değildir. Her downstream tüketici, yeni kanal için eskiler için ürettiği aynı doğru cevabı ürettiğinde bitmiştir. Bunun altındaki her şey ertelenmiş bir vakadır.