COBOL’dan Java’ya Geçerken Aslında Neyi Taşıyoruz?
Bir programlama dilini değiştirmek bazen kolaydır. Otuz yıllık iş mantığını kaybetmeden taşımak ise bambaşka bir mühendislik problemidir.
Bir bankanın teknoloji ekibinde çalıştığınızı düşünün.
Yıllardır kullanılan bir sistem var. Her gün binlerce işlem gerçekleştiriyor, hesaplamalar yapıyor, kayıtları güncelliyor ve gece olduğunda belirli işlemleri tamamlamak için yeniden çalışmaya başlıyor.
Sistemin arayüzü belki çok eski. Kodları yıllar önce yazılmış. Yeni bir özellik eklemek haftalar sürebiliyor. Üstelik sistemi geliştiren mühendislerin önemli bir kısmı artık kurumda çalışmıyor.
Ama sistem çalışıyor.
Hem de yıllardır.
Bir gün yönetimden beklenen karar geliyor:
“Artık bu sistemi modernize edelim. COBOL’dan Java’ya geçiyoruz.”
Toplantılar yapılıyor, ekipler oluşturuluyor, proje takvimi hazırlanıyor. Mevcut kodlar inceleniyor, hedef mimari üzerine konuşuluyor.
İlk bakışta yapılacak iş belli.
Eski kodu anlayacağız, Java ile yeniden geliştireceğiz, test edeceğiz ve yeni sisteme geçeceğiz.
Peki gerçekten bu kadar basit mi?
Asıl hikâye, geliştirme ekibinin yıllar önce yazılmış bir koşulun neden hâlâ orada durduğunu anlamaya çalışmasıyla başlıyor.
Kimsenin hatırlamadığı bir iş kuralı
Diyelim ki bir sigorta şirketinin poliçe hesaplama sistemini dönüştürüyorsunuz.
Kodları incelerken belirli bir tarihten önce düzenlenen poliçeler için farklı bir hesaplama yapıldığını fark ediyorsunuz.
Koşul açık. Hesaplama belli.
Fakat neden böyle yapıldığına ilişkin bir açıklama yok.
Analiste soruyorsunuz, bilmiyor. İş birimiyle görüşüyorsunuz, onlar da mevcut uygulamanın neden böyle davrandığından emin değil.
Belki geçmişte yapılan bir ürün değişikliği nedeniyle eklenmişti. Belki eski bir sözleşme grubuna özel uygulanıyordu. Belki de yıllar önce düzeltilmesi gereken ama sistemde kalmış bir davranıştı.
Şimdi bir karar vermeniz gerekiyor.
Bu kuralı Java tarafına aynen mi taşıyacaksınız?
Yoksa artık gerekli olmadığını düşünerek kaldıracak mısınız?
İşte modernizasyon projelerini sıradan yazılım geliştirme projelerinden ayıran önemli noktalardan biri burada ortaya çıkıyor.
Eski bir sistemin içerisinde yalnızca kod bulunmaz. Kurumun yıllar içerisinde verdiği kararların izleri de bulunur.
Bu kararların bazıları dokümante edilmiştir. Bazıları ise yalnızca çalışan sistemin davranışında yaşamaya devam eder.
Üstelik eski sistemin yaptığı her şeyin doğru olduğunu da varsayamayız.
Bazen yıllardır çalışan bir hesaplama hatalı olabilir. Ancak o hatanın düzeltilmesi bile müşterileri, finansal kayıtları veya başka sistemleri etkileyebilir.
Dolayısıyla modernizasyon, geçmişteki bütün davranışları sorgulamadan kopyalamak değildir.
Hangi davranışın korunması, hangisinin değiştirilmesi gerektiğini kanıtlarıyla belirlemektir.
Kodları çevirmek neden yeterli değil?
COBOL’dan Java’ya dönüşüm denildiğinde çoğu insanın aklına doğal olarak kaynak kodun başka bir programlama dilinde yeniden yazılması geliyor.
Oysa dönüşümün kapsamı çoğu zaman bundan çok daha büyük.
COBOL uygulamasındaki bir program, başka programlarla ilişkili olabilir. Ortak veri tanımları kullanabilir. Gün sonunda çalışan bir batch sürecinin belirli aşamasında devreye girebilir.
Örneğin bir bankada gün sonu işlemlerini düşünelim.
Gün içerisinde oluşan hareketler toplanıyor, hesaplamalar gerçekleştiriliyor, belirli kayıtlar güncelleniyor ve sonuçlar başka sistemlere aktarılıyor.
Bu işlemler arasında bir sıra bulunuyor.
Bir hesaplama tamamlanmadan başka bir işlem başlayamıyor. Bir dosya oluşturulmadan sonraki adım çalışamıyor.
Siz COBOL kodlarını Java’ya doğru şekilde çevirmiş olabilirsiniz.
Ancak işlem sırasını değiştirdiyseniz, verilerin işlenme biçimini farklılaştırdıysanız veya bir hata durumundaki davranışı atladıysanız ortaya çıkan sonuç eski sistemle aynı olmayabilir.
Mainframe dünyasında JCL gibi mekanizmalar, batch işlerinin hangi programlarla, girdilerle ve adımlarla çalışacağını tanımlar.
Copybook’lar ise programlar arasında kullanılan veri yapılarını anlamamız açısından önemlidir.
Bunları incelemeden yalnızca kaynak kod üzerinden yapılan dönüşüm, sistemin gerçekte nasıl çalıştığına ilişkin eksik bir resim oluşturabilir.
Bir başka konu da sayısal hesaplamalar.
Finansal sistemlerde küçük bir yuvarlama farkı bile önemli olabilir.
COBOL’da kullanılan sabit noktalı ondalık veri türleriyle Java’daki sayısal veri türlerinin davranışları birebir aynı değildir.
Java’da finansal hesaplamalar için çoğunlukla BigDecimal tercih edilir. Ancak yalnızca BigDecimal kullanmak da yeterli değildir.
Hassasiyet, yuvarlama yöntemi, hesaplama sırası ve ara sonuçların nasıl ele alındığı doğru belirlenmelidir.
Çünkü bir finansal sistemde sorun her zaman işlemin başarısız olması değildir.
Bazen işlem başarıyla tamamlanır.
Sadece sonuç, olması gerekenden birkaç kuruş farklıdır.
Ve bu fark milyonlarca işlem boyunca tekrarlandığında artık küçük bir ayrıntı olmaktan çıkar.
Yeni mimari gerçekten daha iyi mi?
Modernizasyon projelerinde en çok konuşulan konulardan biri hedef mimaridir.
Microservices mi kullanılmalı? Modüler monolit daha mı uygun? Mevcut sistem tamamen mi yeniden yazılmalı, yoksa belirli bölümler aşamalı olarak mı dönüştürülmeli?
Bu soruların tek bir doğru cevabı yok.
Ancak burada sık karşılaştığımız bir düşünce biçimi var.
Eski sistem monolitik olduğu için yeni sistemin mutlaka mikroservis mimarisinde olması gerektiğini varsayabiliyoruz.
Oysa bir sistemi çok sayıda servise bölmek, onu kendiliğinden daha anlaşılır veya daha kolay yönetilebilir hâle getirmez.
Önce iş alanlarının sınırlarını, verinin sahipliğini, süreçlerin birbirine olan bağımlılıklarını ve operasyonel ihtiyaçları anlamamız gerekir.
Aksi durumda eskiden tek uygulamanın içerisinde bulunan karmaşıklığı bu kez servisler arasındaki iletişime taşırız.
Üstelik dağıtık işlemler, ağ gecikmeleri, hata yönetimi ve veri tutarlılığı gibi yeni problemlerle de karşılaşabiliriz.
Bence burada sorulması gereken asıl soru şu:
“Yeni sistemimiz hangi problemi çözecek?”
Daha hızlı değişiklik yapabilmek mi istiyoruz?
Yeni ürünleri daha kolay geliştirmek mi?
Mevcut teknolojiye bağımlılığı azaltmak mı?
Operasyonel maliyetleri düşürmek veya sistemin bakımını sürdürülebilir hâle getirmek mi?
Hedefimiz net değilse, en güncel teknolojilerle geliştirdiğimiz sistem bile birkaç yıl içerisinde yeni bir legacy uygulamaya dönüşebilir.
Modern bir teknoloji kullanmakla sürdürülebilir bir sistem tasarlamak aynı şey değil.
Peki yeni sistemin doğru çalıştığını nasıl anlayacağız?
Buraya kadar her şey yolunda ilerlemiş olsun.
Get Umut Akbulut’s stories in your inbox
Join Medium for free to get updates from this writer.
Mevcut sistem analiz edildi. İş kuralları belirlendi. Java uygulaması geliştirildi. Mimari kararlar alındı.
Şimdi test zamanı.
Normal bir yazılım projesinde gereksinimlere göre test senaryoları hazırlarız. Beklenen sonuçları tanımlar, uygulamanın bunları karşılayıp karşılamadığını kontrol ederiz.
Modernizasyon projelerinde ise elimizde başka bir referans daha bulunur.
Yıllardır üretim ortamında çalışan eski sistem.
Bu önemli bir avantajdır.
Aynı girdileri eski ve yeni sistemde çalıştırarak sonuçlarını karşılaştırabiliriz.
Ancak burada dikkat edilmesi gereken bir ayrıntı var.
İki sistemin aynı sonucu üretmesi, sonucun mutlaka doğru olduğu anlamına gelmez.
Sadece iki sistemin o senaryoda aynı davrandığını gösterir.
Bu nedenle karşılaştırma testlerini iş kuralları ve beklenen davranışlarla birlikte ele almak gerekir.
Özellikle finansal sistemlerde yalnızca başarılı işlemleri değil, istisnai durumları da test etmek gerekir.
İptal edilen işlemler, geriye dönük tarihli kayıtlar, farklı para birimleri, eski sözleşmeler, hatalı veri girişleri ve yarım kalan batch süreçleri bunlardan yalnızca birkaçı.
Bir de performans konusu var.
Gece başlayan ve sabah mesai açılmadan tamamlanması gereken bir batch işlemini düşünelim.
Eski sistem bu işi iki saatte bitiriyor.
Yeni sistem bütün hesaplamaları doğru yapıyor ama işlem altı saat sürüyor.
Fonksiyonel açıdan başarılı görünen dönüşüm, operasyonel açıdan beklentiyi karşılamayabilir.
Bu yüzden kritik dönüşümlerde gerçekçi veri hacimleriyle performans testleri yapmak, veri ve işlem sonuçlarını mutabıklaştırmak, uygun senaryolarda eski ve yeni sistemi paralel çalıştırmak önemlidir.
Geçiş anını da en az geliştirme süreci kadar dikkatli planlamak gerekir.
Çünkü canlı ortama geçiş yalnızca yeni uygulamanın devreye alınması değildir.
Verinin, iş akışlarının, diğer sistemlerle entegrasyonların ve operasyonel sorumlulukların da kontrollü şekilde devredilmesidir.
Yapay zekâ bu sürecin neresinde?
Son dönemde legacy modernizasyon çalışmalarında yapay zekânın kullanımı da giderek önem kazanıyor.
Özellikle büyük kaynak kod havuzlarının analiz edilmesi, programlar arasındaki bağımlılıkların çıkarılması, dokümantasyon taslaklarının oluşturulması ve olası iş kurallarının belirlenmesi gibi alanlarda AI destekli araçlardan yararlanılabiliyor.
Bu oldukça değerli.
Çünkü dönüşüm projelerinde önemli bir zaman, mevcut sistemin anlaşılmasına harcanıyor.
Yapay zekâ bu keşif sürecini hızlandırabilir.
Ancak burada da dikkatli olmamız gereken bir sınır var.
Bir AI modelinin kaynak koddan iş kuralı çıkarması, o kuralın bütün iş bağlamını doğru anladığı anlamına gelmez.
Örneğin model, belirli müşteriler için farklı hesaplama yapıldığını tespit edebilir.
Ama bu davranışın hangi mevzuat değişikliğinden kaynaklandığını, hâlâ geçerli olup olmadığını veya kaldırılması durumunda hangi operasyonların etkileneceğini yalnızca kod üzerinden kesin olarak bilemeyebilir.
Bu nedenle AI çıktılarının kaynak kod, veri, sistem davranışı ve iş birimi bilgisiyle doğrulanması gerekir.
Burada en güçlü yaklaşımın, yapay zekâyı mühendislerin yerine karar veren bir mekanizma olarak değil, onların daha hızlı ve kapsamlı analiz yapmasını sağlayan bir araç olarak konumlandırmak olduğunu düşünüyorum.
AI bize olası bağımlılıkları gösterebilir.
Riskli alanları işaretleyebilir.
Test senaryoları önerebilir.
Ancak özellikle finansal sonuç doğuran kritik kararların doğrulanması, izlenebilirliği ve onaylanması yine disiplinli bir mühendislik sürecini gerektirir.
Modernizasyonun görünmeyen tarafı: İnsanlar
Bütün bu teknik konuların arasında bazen daha temel bir şeyi unutuyoruz.
Bir dönüşüm projesi yalnızca teknolojinin değişmesi değil, yıllardır kullanılan bir sistem hakkındaki bilginin de aktarılmasıdır.
Eski sistemi iyi tanıyan bir uzman, kaynak kodda yazmayan bir operasyonel detayı biliyor olabilir.
Bir iş analisti, belirli hesaplamanın neden farklı çalıştığını hatırlayabilir.
Operasyon ekibindeki bir çalışan, gece tamamlanmayan bir işlemin ertesi gün hangi süreçleri etkileyeceğini deneyimlerinden biliyor olabilir.
Bu bilgiye yeterince değer vermeden yalnızca kaynak kodu incelemek, dönüşüm projesini gereksiz risklerle karşı karşıya bırakabilir.
Bu yüzden iyi bir modernizasyon ekibinde sadece Java ve COBOL geliştiricilerinin bulunması yeterli değildir.
İş analistleri, test mühendisleri, mimarlar, veri uzmanları, kalite ekipleri ve operasyon tarafının birlikte çalışması gerekir.
Proje yönetimi de tam olarak burada önem kazanır.
Çünkü teknik işlerin tamamlanmasını takip etmek başka bir şeydir.
Bir kurumun kritik iş süreçlerini kesintiye uğratmadan dönüştürmesini yönetmek bambaşka bir sorumluluktur.
Sonuçta neyi modernize ediyoruz?
Başlangıçtaki bankaya geri dönelim.
Yıllardır çalışan COBOL sistemi artık Java ile yeniden geliştirildi.
Kodlar daha okunabilir. Yeni mimari kuruldu. Otomatik testler hazırlandı. Dağıtım süreçleri iyileştirildi.
Peki proje başarılı mı?
Bence bu sorunun cevabını yalnızca kullanılan teknolojiye veya tamamlanan geliştirme işlerine bakarak veremeyiz.
Sistem aynı iş ihtiyaçlarını güvenilir biçimde karşılıyor mu?
Kritik iş kuralları açıkça tanımlanmış mı?
Yeni bir ürün veya değişiklik eskisine göre daha kolay hayata geçirilebiliyor mu?
Olası bir hatanın nereden kaynaklandığını anlayabiliyor muyuz?
Ve belki de en önemlisi, bundan on yıl sonra bu sistemi geliştirecek mühendisler bugün bizim yaşadığımız belirsizliklerle yeniden karşılaşacak mı?
Bu sorulara verdiğimiz cevaplar, modernizasyonun gerçek başarısını daha iyi anlatacaktır.
Çünkü COBOL’dan Java’ya geçerken aslında yalnızca kod taşımıyoruz.
Bir kurumun yıllar içerisinde oluşturduğu iş bilgisini, operasyonel deneyimini ve kritik kararlarını da yeni bir teknoloji ortamına aktarıyoruz.
Bunu doğru yapabilirsek yalnızca eski bir sistemi değiştirmiş olmayız.
Gelecekte geliştirilmesi, anlaşılması ve yönetilmesi daha kolay bir sistemin temelini atmış oluruz.
Belki de modernizasyonun gerçek başarısı, eski koddan ne kadar kurtulduğumuzla değil, eski sistemin taşıdığı bilgiyi ne kadar iyi koruyup anlaşılır hâle getirdiğimizle ölçülmeli.
Kaynaklar ve ileri okuma
- IBM — COBOL sayısal veri gösterimi ve packed-decimal veri türleri
- IBM — z/OS ortamında JCL ve batch iş yönetimi
- AWS Prescriptive Guidance — Mainframe Modernization: Decoupling Patterns
- AWS Prescriptive Guidance — Mainframe Modernization: Assessment
- AWS Prescriptive Guidance — AI Destekli Mainframe Modernizasyonu ve Kod Analizi
