Eski sistemi durdurmadan yazılım modernizasyonu: aşamalı geçiş rehberi

Tek seferlik büyük geçiş neden riskli?

Eski bir sistemi yenilemenin ilk akla gelen yolu, yeni sistemi baştan yazıp belirli bir tarihte topluca geçmektir. Sektörde “big bang” geçiş olarak bilinen bu yaklaşım kâğıt üzerinde temizdir: tek proje, tek geçiş günü, eski sistem o gün kapanır. Pratikte ise üç sorun aynı anda büyür.

• Uzun dondurma dönemi. Yeni sistem hazırlanırken eskisine yeni özellik eklemek ya ertelenir ya da iki kez yapılır. İş birimleri aylarca bekler; beklerken geçici çözümler, yani yeni bir Excel dosyası ya da ek bir onay e-postası, çoğalır.
• Tek seferde veri taşıma. Yıllar içinde birikmiş veri; belgelenmemiş alanlar, tutarsız kayıtlar ve özel durumlarla doludur. Hepsini bir gecede taşımak, sorunların ilk kez canlı ortamda ortaya çıkması demektir.
• Hareket eden hedef. Proje sürerken iş değişmeye devam eder: yeni ürünler, yeni mevzuat, yeni iş ortakları. Yeni sistem tamamlandığında, başlangıçta yazılan gereksinimlerin bir kısmı geçerliliğini yitirmiş olur.

Bunlara gizli iş kuralları eklenir. Eski sistemlerde kuralların önemli bir kısmı yalnızca kodda ve birkaç deneyimli çalışanın hafızasında yaşar. Sıfırdan yazımda bu kuralların bazıları ancak geçişten sonra, bir şey ters gittiğinde fark edilir.

Strangler fig: eskiyi sararak yenilemek

Alternatif, sistemi parça parça değiştirmektir. Yazılım dünyasında “strangler fig” (boğucu incir) adıyla bilinen ve Martin Fowler’ın yaygınlaştırdığı bu model, adını bir ağaç türünden alır: boğucu incir başka bir ağacın üzerinde filizlenir, köklerini yavaş yavaş toprağa indirir ve zamanla taşıyıcı ağacın yerini alır. Taşıyıcı ağaç bu süre boyunca ayakta kalır.

Yazılımdaki karşılığı şudur: eski sistemin önüne bir yönlendirme katmanı konur, işlevler tek tek yeni sistemde yeniden yazılır ve her işlev hazır olduğunda o işleve ait trafik yeni sisteme yönlendirilir. Eski sistem, son modülü de devredilene kadar çalışmaya devam eder. Her aşama kendi başına canlıya çıkar; kullanıcılar yeni sistemin değerini programın sonunda değil, ilk aşamada görmeye başlar.

Aşamalı geçiş daha az iş demek değildir. Bir süre iki sistemi birlikte işletmek ve aralarındaki veri akışını yönetmek ek çaba ister. Karşılığında risk küçük parçalara bölünür; her parça ölçülebilir ve geri alınabilir hale gelir.

Aşamalı geçişin adımları

Aşağıdaki adımlar her modül için tekrarlanan bir döngüdür. Anlatımı somutlaştırmak için varsayımsal bir örnek kullanalım: Diyelim ki bir dağıtım şirketinin sipariş, fiyatlandırma, stok, faturalama ve raporlama işlevleri, yirmi yıldır geliştirilen tek bir eski (legacy) sistemde çalışıyor.

1. Modülleri, bağımlılıkları ve veriyi haritalayın

Önce sistemin gerçekte ne yaptığını çıkarın: hangi işlevler var, hangi ekip hangisini kullanıyor, hangi modül hangi tabloya yazıyor, hangi gece işleri ve entegrasyonlar çalışıyor. Bu harita kod incelemesiyle ve kullanıcıları iş başında gözlemleyerek birlikte çıkarılır; ikisinden biri tek başına eksik kalır. Her veri türü için doğruluk kaynağının hangi sistem olduğunu da bu aşamada yazılı hale getirin.

2. İlk dilimi seçin

İyi bir ilk dilim iş için görünür bir değer üretir, az bağımlılığa sahiptir ve sonucu ölçülebilir. Örnekteki faturalama cazip görünebilir, ama muhasebe, stok ve vergi entegrasyonlarına bağlıdır; ilk adım için ağırdır. Satış ekibinin her gün kullandığı teklif hazırlama ekranı çoğu zaman daha iyi bir adaydır: sık kullanılır, yavaşlığı herkesçe bilinir ve yalnızca birkaç tabloya dokunur. Yalnızca okuma yapan raporlama da düşük riskli bir başlangıçtır, ancak değeri sınırlı kalabilir.

3. Önüne bir yönlendirme katmanı koyun

Kullanıcılar ve diğer sistemler eski sisteme doğrudan değil, bir API ağ geçidi ya da yönlendirme katmanı üzerinden erişir. Başlangıçta bu katman tüm istekleri eski sisteme iletir; hiçbir şey değişmez. Sonraki her aşamada yalnızca ilgili istekler yeni sisteme yönlenir. Arayüz tarafında aynı rolü, eski ve yeni ekranları tek bir menü altında birleştiren bir kabuk uygulama üstlenebilir.

4. Veriyi iki sistem arasında senkron tutun

Geçiş süresince aynı veri iki sistemde birden yaşar. İki yaygın yöntem vardır:

• Çift yazma: Uygulama her değişikliği hem eski hem yeni veritabanına yazar. Kurması basittir; ancak yazmalardan biri başarısız olduğunda iki taraf ayrışır, bu yüzden sağlam hata yönetimi ve düzenli mutabakat gerekir.
• Değişiklik verisi yakalama (CDC): Eski veritabanının işlem günlüğündeki değişiklikler okunur ve yeni sisteme olay olarak aktarılır. Eski koda dokunmadan senkron sağladığı için, kodunu değiştirmek riskli olan sistemlerde çoğu zaman tercih edilir.

Hangisi seçilirse seçilsin, her kayıt için tek bir doğruluk kaynağı olmalı ve iki tarafı karşılaştıran bir mutabakat raporu düzenli çalışmalıdır. Bir modül yeni sisteme geçtiğinde doğruluk kaynağı da yer değiştirir; senkronun yönü bu noktada tersine döner.

5. Paralel çalıştırın ve karşılaştırın

Yeni modül canlıya alınmadan önce bir süre gölge modda çalışır: aynı istekler iki sisteme de gider, kullanıcıya eski sistemin yanıtı döner, yeni sistemin yanıtı yalnızca karşılaştırma için kaydedilir. Farklar, gizli iş kurallarını yakalamanın en güvenilir yoludur. Örneğin belirli bir bayi grubuna yalnızca ay sonunda uygulanan bir iskonto, belgelerde değil bu karşılaştırmada ortaya çıkar.

6. Trafiği kademeli kaydırın

Farklar kabul edilebilir düzeye indiğinde trafik adım adım yeni modüle geçer: önce iç kullanıcılar, sonra bir bölge ya da bayi grubu, ardından herkes. Geçiş bir özellik bayrağıyla yönetilir; sorun çıkarsa geri dönüş tek adımdır ve önceden prova edilmiştir.

7. Eski modülü kapatın ve ölçün

Trafik tamamen yeni modüle geçtiğinde eski modülü gerçekten kapatın: kod yollarını kaldırın, gece işlerini durdurun, gerekli veriyi arşivleyin. Kapatılmayan her eski modül, bakımı süren ikinci bir sistem demektir. Ardından aşamayı baştan belirlenen ölçütlerle değerlendirin: işlem süresi, hata oranı, yanıt süresi, eski ekranlara dönüş talepleri ve eski sistemin işletme maliyeti. Karşılaştırmanın anlamlı olması için başlangıç değerlerini geçişten önce kaydetmiş olmanız gerekir.

Takvim: ilk aşama ne zaman canlıya çıkar?

Aşamalı modernizasyonun takvimi tek bir teslim tarihi değil, bir yol haritasıdır. Bizim çalışma biçimimizde program şöyle ilerler:

• Keşif (1–2 hafta): Sistem, veri ve süreç haritası; risk haritası; ilk dilim önerisi. Keşif sprintinin içeriğini ve çıktılarını ayrı bir yazıda ele alıyoruz.
• Tanım ve prototip (2–3 hafta): İlk dilimin ekranları ve entegrasyon tasarımı; prototip 3. haftada gerçek kullanıcılarla test edilir.
• İnşa (2 haftalık sprintler): Her hafta çalışan yazılım gösterilir; kapsamı birlikte belirlenen ilk aşama 6–12 haftada canlıya çıkar.
• Sonraki aşamalar: Diğer modüller yol haritasında sıralanır; her biri aynı döngüyle, kendi başına canlıya çıkar.

Çekirdek sistem modernizasyonu gibi büyük programlar tek bir 6–12 haftalık projeye sığmaz ve sığdırılmaya çalışılmamalıdır. Bu sürenin programın tamamını değil, ilk aşamayı kapsadığını baştan açıkça konuşmak beklentileri doğru kurar.

Riskler ve nasıl azaltılır

Aşamalı geçiş riski ortadan kaldırmaz; onu görünür kılar ve küçük parçalara böler. Bu tür programlarda öne çıkan riskler ve karşı önlemler:

Bir de organizasyonel risk vardır: eski sistemi en iyi tanıyan kişiler genellikle günlük işin yükünü de taşır. Keşif ve paralel çalıştırma dönemlerinde bu kişilerin zamanını önceden planlamak, teknik önlemler kadar önemlidir.

Başlamadan önce kontrol listesi

İlk aşamaya başlamadan önce aşağıdaki maddelerin netleşmiş olması, programın geri kalanını da kolaylaştırır.

Bu yaklaşımın ekranlara nasıl yansıdığını Sigorta Altyapı Modernizasyonu ürün konseptinde görebilirsiniz: kurgusal X Sigorta’da ilk aşama, tek ekranlık kasko teklifi ve eski ana sistemle yeni platformu senkron tutan bir olay köprüsüdür. Kapsam ve teslimatlar için platform modernizasyonu yetkinliğimize bakabilirsiniz.

Kendi sisteminiz için ilk dilimi birlikte belirlemek isterseniz, bir keşif sprinti için görüşme talep edin.