Sahada en sık karşılaştığım programlardan biri, kurucusunun ya da emekli olmuş bir yazılımcının yıllar önce yazdığı, hâlâ tüm üretimi ya da muhasebeyi taşıyan o eski uygulamadır. Delphi 7 ile yapılmış bir stok programı, Visual Basic 6 ile yazılmış bir sipariş takip ekranı, FoxPro üzerinde çalışan bir cari hesap sistemi... Bunlar genellikle çok stabil çalışır, herkes nasıl kullanılacağını ezbere bilir ve tam da bu yüzden değiştirilmesi en zor yazılımlardır. Bu yazıda, böyle bir sistemi ne zaman taşımanız gerektiğini, veriyi kaybetmeden nasıl taşıyacağınızı ve maliyeti gerçekte neyin belirlediğini, abartıya kaçmadan anlatmak istiyorum.
Çalışan bir programı değiştirmek gerçekten gerekli mi?
İlk söyleyeceğim şey belki beklediğinizin tersi olacak: çalışan bir sistemi sırf eski diye değiştirmem. "Yeni teknolojiyle yapalım" hevesiyle başlayan birçok projenin, aslında hiç dokunulmaması gereken stabil bir yazılımı bozduğunu gördüm. Modernizasyon bir moda değil, bir ihtiyaçtır.
Peki ihtiyaç ne zaman gerçek bir ihtiyaca dönüşür? Genellikle şu işaretlerden birkaçı bir araya geldiğinde:
- İşletim sistemi uyumu kayboluyor: Yeni Windows sürümlerinde program açılmıyor, yazıcıdan çıktı alınamıyor ya da eski bir DLL bulunamıyor.
- Programı bilen kimse kalmadı: Yazılımı yapan kişiye ulaşılamıyor, kaynak kodu kayıp ya da kimse koda dokunmaya cesaret edemiyor.
- İş süreçleri programı aşmış: E-fatura, e-irsaliye, yeni vergi düzenlemeleri ya da mobil erişim gibi ihtiyaçlar eski yapıya sığmıyor.
- Tek bilgisayara mahkûmsunuz: Program ağ üzerinden düzgün çalışmıyor, uzaktan erişim mümkün değil, veri tek makinede kilitli.
- Veri güvenliği risk altında: Yedekleme zayıf, FoxPro tabloları bozuluyor ya da aynı anda iki kişi girince veri tutarsızlaşıyor.
Bu sinyaller görünmeye başladığında, mesele "değiştirelim mi" değil, "kontrollü mü değiştireceğiz yoksa bir gün çöktüğünde panikle mi" sorusuna dönüşür. Ben her zaman kontrollü olanı öneririm.
Risksiz geçişin temeli: önce anlamak, sonra dokunmak
Eski yazılım projelerinde en büyük hata, mevcut sistemi tam anlamadan yenisini yazmaya başlamaktır. Yıllar içinde bu programlara, hiçbir yerde belgelenmemiş onlarca iş kuralı gömülmüştür: belli bir müşteriye özel iskonto, yıl sonunda devreye giren bir hesaplama, sadece muhasebecinin bildiği bir kısayol. Bunları atlarsanız yeni sistem teknik olarak "daha iyi" ama işi yürütmek için "daha kötü" olur.
Bu yüzden ilk adımım her zaman mevcut sistemi ve veriyi çıkarmaktır. Veritabanı yapısını, tabloları, alanları ve ekranların arkasındaki mantığı haritalarım. FoxPro ve VB6 projelerinde çoğu zaman iş mantığının doğrudan ekran kodunun içine gömülü olduğunu görürsünüz; bu mantığı ayıklayıp belgelemek, projenin en değerli kısmıdır.
Eski bir yazılımı modernize etmek, aslında bir binayı yıkıp yeniden yapmak değil; temeli sağlamsa, üzerine yeni katlar çıkarken içeride oturanları hiç rahatsız etmemektir.
Veriyi kaybetmeden kademeli geçiş
Korkulan senaryo hep aynıdır: "Yeni programa geçtik, eski kayıtların yarısı kayboldu." Bunu önlemenin yolu, geçişi bir gecede yapılan büyük bir patlama olmaktan çıkarıp kademeli ve geri dönülebilir bir sürece çevirmektir. Genellikle şu sırayı izlerim:
1. Veriyi güvenceye almak
İlk iş, mevcut tüm verinin eksiksiz yedeğini almak ve bu yedeği üzerinde çalışılacak bir kopyaya dönüştürmektir. Canlı sisteme hiç dokunmadan, kopya üzerinde çalışırım. Böylece bir hata olsa bile işletmenin günlük işleyişi hiç etkilenmez.
2. Veri taşıma kurallarını yazmak ve test etmek
Eski tablolardaki veriyi yeni yapıya taşıyan bir aktarım süreci kurarım. Bunu bir kere değil, defalarca çalıştırırım. Her seferinde eski ve yeni sistemdeki toplamları karşılaştırırım: cari bakiyeler tutuyor mu, stok adetleri eşit mi, fatura sayıları aynı mı? Rakamlar birebir oturana kadar yeni sistem canlıya alınmaz.
3. Bir süre paralel çalıştırmak
Mümkün olduğunda, kritik bir dönem boyunca eski ve yeni sistemi birlikte çalıştırmayı öneririm. Aynı verinin iki tarafta da aynı sonucu verdiğini gördüğünüzde, ekibin yeni sisteme güveni de oluşur. Bu güven, projenin başarısı için en az teknik doğruluk kadar önemlidir.
4. Modül modül devretmek
Her şeyi aynı anda taşımak yerine, mümkünse önce en az riskli modülü (örneğin raporlama ya da bir alt süreç) yeni sisteme alır, ekibin alışmasını beklerim. Sonra sırayla diğer modülleri devreye alırız. Bu yaklaşım, bir sorun çıktığında onu küçük ve yönetilebilir tutar.
Maliyeti ve süreyi gerçekte ne belirler?
"Bu işi modernize etmek ne kadar tutar?" sorusunun dürüst cevabı, "neyi taşıdığımıza bağlı" şeklindedir. Yine de süreyi ve bütçeyi belirleyen faktörleri net olarak sıralayabilirim:
- Kaynak kodun durumu: Elinizde derlenebilir, düzenli bir kaynak kod varsa iş kolaylaşır. Kod kayıpsa, mantığı çalışan programdan ve veriden geri çıkarmak gerekir ki bu zaman alır.
- Veri kalitesi: Yıllar içinde birikmiş tutarsız, mükerrer ya da bozuk kayıtlar, taşımanın en çok vakit yiyen kısmıdır. Temiz veri, hızlı geçiş demektir.
- Gizli iş kurallarının sayısı: Programın içine gömülü ne kadar çok özel hesaplama ve istisna varsa, bunları yeniden üretmek o kadar uzar.
- Entegrasyon ihtiyaçları: E-fatura, banka, e-ticaret ya da üretim makineleriyle bağlantı gibi dış sistemler işin kapsamını genişletir.
- Aynı anda kaç kullanıcı ve ne hacimde veri: Tek kullanıcılı küçük bir uygulamayla, onlarca kişinin aynı anda kullandığı bir sistem aynı şey değildir.
Bu yüzden size baştan havadan bir rakam söyleyen birine temkinli yaklaşmanızı öneririm. Ben önce mevcut sistemi inceler, kapsamı netleştirir, sonra gerçekçi bir plan ve bütçe çıkarırım. Sürpriz maliyet, hem sizin hem benim en istemediğim şeydir.
Modernizasyon, sıfırdan yazmak zorunda değildir
Son olarak önemli bir noktayı vurgulamak isterim: modernizasyon her zaman "her şeyi baştan yazmak" anlamına gelmez. Bazen mevcut veritabanını koruyup üzerine modern bir web arayüzü eklemek, bazen sadece raporlamayı ve mobil erişimi çağdaşlaştırmak yeterlidir. Çözümü işinize göre seçerim, hazır bir kalıba sizi sokmaya çalışmam. Amacım, kullandığınız sistemi yıllarca güvenle çalışacak, bakımı kolay ve büyümenize ayak uyduran bir yapıya kavuşturmaktır.
Eğer Delphi, Visual Basic 6 ya da FoxPro ile yazılmış bir yazılımınız varsa ve "bir gün bu çökerse ne yaparız" düşüncesi içinizi rahatsız ediyorsa, bunu konuşmaktan çekinmeyin. Mevcut sisteminize hiç zarar vermeden, verilerinizi güvenceye alarak ve sizi gereksiz bir maliyetin altına sokmadan en doğru yolu birlikte değerlendirebiliriz. Dilerseniz mevcut yapınıza bir göz atıp size dürüst bir değerlendirme sunabilirim.