ERP sistemlerinde şema değişikliği çoğu zaman yalnızca bir veri tabanı işi gibi ele alınır. Oysa gerçek hayatta değişen şey tablo değil, aynı anda çalışan entegrasyonlar, batch akışları, raporlama sorguları ve operasyon ekiplerinin hata ayıklama kabiliyetidir. Bu nedenle sağlıklı bir ERP modernizasyonunda hedef “migration çalıştı” demek değil, değişikliği gerektiğinde güvenle geri alabilecek bir şema geçiş hattı kurmaktır.
Neden ERP tarafında şema değişikliği daha hassastır?
Çünkü ERP verisi genellikle tek bir uygulamanın değil, onlarca iş akışının ortak sözleşmesidir. Bir alan adının değişmesi ya da zorunlu bir kolon eklenmesi şu katmanları aynı anda etkileyebilir:
- Uygulama sunucuları
- ETL ve raporlama akışları
- Entegrasyon servisleri
- Batch işleyiciler
- Yetki ve denetim kayıtları
Modern mikroservislerde bu etki bazen servis sınırında kalabilir; ancak ERP dünyasında değişiklik çoğu zaman yatayda daha fazla sisteme dokunur. Bu yüzden geri dönüşlü tasarım temel gereksinimdir.
Geri dönüşümlü şema geçiş hattı nedir?
Ben bu modeli dört aşamalı düşünmeyi faydalı buluyorum:
- Uyumluluk genişletmesi: Yeni şema alanlarını ekle ama mevcut davranışı bozma.
- Çift okuma veya çift yazma dönemi: Uygulama eski ve yeni yapıyı kontrollü biçimde birlikte kullanır.
- Trafik ve veri gözlemi: Hangi bağımlılığın hâlâ eski alanı kullandığını telemetriyle teyit et.
- Daraltma ve temizlik: Eski alanı yalnızca gerçekten terk edildiği doğrulandıktan sonra kaldır.
Bu yaklaşımın temel avantajı, değişikliği tek adımda geri dönülmez bir harekete çevirmemesidir.
Asıl hata nerede yapılıyor?
Çoğu ekip migration dosyasını başarıyla çalıştırdığında işin bittiğini düşünüyor. Oysa kırılma genellikle iki gün sonra, gece batch’inde, bir raporlama sorgusunda veya dış entegrasyonda ortaya çıkıyor. Bunun sebebi, şema değişikliğinin teknik olarak uygulanmış ama davranışsal etkisinin ölçülmemiş olmasıdır.
Bu yüzden geçiş hattının içine şu kontrol kapıları yazılmalıdır:
- Hangi sorgular eski alanı kullanıyor?
- Hangi entegrasyon sürümü yeni şemayı tüketemiyor?
- Hangi batch job veri tutarsızlığı üretiyor?
- Rollback yapılırsa veri kaybı mı yoksa yalnızca davranış değişimi mi olur?
Uyumluluk katmanını küçümsemeyin
ERP altyapılarında uyumluluk katmanı bazen geçici diye hafife alınır; aslında en değerli koruma yüzeyidir. Örneğin yeni bir document_status_v2 alanı ekleniyorsa uygulama bir süre hem eski hem yeni alanı okuyabilir. Hatta gerekli durumlarda yazma sırasında dönüştürme adaptörü kullanılarak iki yapı paralel tutulabilir.
Bu katman sayesinde:
- Uygulama ekipleri farklı sürümlerle kontrollü geçiş yapar.
- Raporlama ekibi sorgularını gecikmeli ama güvenli biçimde uyarlayabilir.
- Beklenmeyen hatada eski davranışa dönmek veri bütünlüğünü bozmaz.
Buradaki kritik nokta, bu dönemi sonsuz bırakmamak ve çıkış kriterlerini baştan tanımlamaktır.
Telemetri olmadan bu hat yönetilemez
Şema geçiş hattı gözlemlenebilir değilse ekipler kararlarını sezgiyle verir. Ben bu tür dönüşümlerde en az şu sinyallerin izlenmesini gerekli görüyorum:
- Eski ve yeni alan kullanım oranı
- Migration sonrası hata sınıfları
- Rapor ve entegrasyon sorgularında başarısızlık oranı
- Veri eşleme veya dönüştürme gecikmesi
Özellikle ERP tarafında “kırıldı mı?” sorusundan çok “kim hâlâ eski davranışa bağımlı?” sorusu daha değerlidir. Bu da ancak uygulama ve veri katmanı birlikte gözlemlendiğinde ortaya çıkar.
Değişiklik penceresi yerine karar penceresi
Kurumsal ekipler çoğu zaman gece yayın penceresi planlar; ama asıl ihtiyaç duyulan şey karar penceresidir. Yani yayın anında hangi sinyal gelirse devam edileceği, hangi sinyalde durulacağı ve hangi koşulda geri dönüleceği önceden net olmalıdır. Bu modelde değişiklik bir cesaret testi değil, kontrollü seçenek yönetimidir.
Bence iyi tanımlanmış bir karar penceresi şunları içerir:
- Sorumlu teknik kişi
- İş etki temsilcisi
- Veri bütünlüğü kontrol listesi
- Rollback sınırı ve veri geri alma yöntemi
Sonuç
ERP altyapılarında geri dönüşümlü şema geçiş hattı, veri tabanı değişikliğini operasyonel bir güven modeliyle birlikte ele alır. Uyumluluk katmanı, telemetri ve net rollback kapıları olmadan yapılan migration’lar ilk anda başarılı görünse de kurumsal ölçekte pahalı sürprizler üretir. Sağlam yaklaşım, değişikliği küçük adımlarla genişletmek, davranışı ölçmek ve yalnızca bağımlılıklar gerçekten taşındığında daraltmaktır.