Eski bir sistemi modernize etmenin 4 yolu var: olduğu gibi buluta taşımak, kodunu modern bir platforma dönüştürmek, çıkardığınız iş kurallarının etrafında yeniden kurmak ya da hazır bir ürünle değiştirip yalnızca verilerini tutmak. Kararı 4 soru verir: Kurallarınız şirketinize özgü mü? Sorun sistemin çalıştığı yerde mi, yoksa sistemin kendisinde mi? Kodunu hâlâ kim anlıyor? Çalışanlarınız ne kadar değişikliği kaldırabilir? Amazon bu yolları 7 stratejide, Microsoft ise 8 stratejide toplar; ikisi de kararı sistem sistem verir.

4. bölümde sisteminizin iş kurallarını çıkardınız ve süreç sahiplerine onaylattınız. Aşağıdaki karşılaştırmayı mümkün kılan bu kurallardır: onlar olmadan her yolda hangi davranışı kaybedeceğinizi bilemezsiniz.

Dört yol, sade bir dille

Teknik adlar çok, ama her yöneticinin izleyebileceği 4 karara indirgenir. Bu tablo onları karşılaştırıyor; parantez içindeki adlar tedarikçilerden duyacağınız terimlerdir:

YolNe zaman uyarNeyi korurNeyi riske atarKimler dahil olmalı
Olduğu gibi taşımak (Rehost)Sistem kararlı ve işini yapıyor; sorun sunucularda ya da veri merkezindeHer şeyi: kodu, kuralları ve çalışma biçiminiEski sorunları yeni bir yere taşırsınızBT ve güvenlik ile verilerden sorumlu kişi
Kodu dönüştürmek (Replatform veya Refactor)Kurallar sağlam ama dilin ya da platformun desteği bitmiş veya lisansları yük olmuşKuralları ve sistemin davranışını, modern bir dil ya da platformdaYalnızca nadir durumlarda ortaya çıkan gizli dönüşüm hatalarıGeliştiriciler ve sonuçları test etmek için süreç sahipleri
Kuralların etrafında yeniden kurmak (Rebuild)Kurallar şirketinize özgü ve sizi farklı kılıyor, eski sistem de artık ihtiyacınızı karşılayamıyorOnaylanmış kuralları ve verileri; kod sıfırdan yazılırEn uzun yol ve yönetimden en çok karar gerektiren yolYönetim, süreç sahipleri ve geliştirme ekibi birlikte
Hazır bir ürünle değiştirmek (Replace)Bu alandaki işiniz başkalarınınkine benziyor, örneğin insan kaynakları ya da genel muhasebeYalnızca verileriÇalışanlarınız çalışma biçimini ürüne uydurur ve ürünün desteklemediği kuralları kaybedersinizYönetim ve onu her gün kullanacak çalışanlar

Kaynak kod, sistemin yazıldığı program metnidir. Elinizde yoksa ya da artık kimse onu anlamıyorsa dönüştürme yolu zorlaşır; Amazon'un strateji kılavuzu, kimsenin nasıl bakım yapacağını bilmediği ya da kaynak kodu bulunmayan bir uygulamayı yeniden tasarıma iten durumlar arasında sayar.

Yapay zekâ ile dönüştürme araçları nereye oturur

AWS Transform gibi araçlar esas olarak ikinci yolda çalışır: eski kodu okur ve modern bir platforma dönüştürür; örneğin eski .NET Framework uygulamalarını Linux üzerinde çalışan modern bir sürüme taşır. Amazon, aracın Windows, mainframe ve VMware uygulamalarını 5 kata kadar daha hızlı modernize ettiğini söylüyor; bu, Amazon'un kendi hizmeti hakkındaki iddiasıdır, garanti edilmiş bir sonuç değildir. Fiyat sayfasına göre hizmet ajan dakikası başına 0,035 dolar ücret alır ve kullanıcının boşta geçen süresini ücretlendirmez.

Ancak araç yolu sizin yerinize seçmez. Dönüştürme doğru karar olduğunda dönüşümü hızlandırır; en iyi cevap sistemi hazır bir ürünle değiştirmekse pek işe yaramaz. Ayrıca bölgeler sayfasında Orta Doğu'da hiçbir bölge yer almıyor ve verilerinizin başka bir bölgede işlenebileceği uyarısı yapılıyor; öte yandan Suudi Basın Ajansına göre Amazon, Krallık'taki bulut bölgesini Aralık 2026 için duyurdu. Kodunuz müşteri verisi içeriyorsa başlamadan önce nerede işleneceğini kontrol edin.

Maliyeti ve süreyi ne belirler

Size bir rakam vermeyeceğiz, çünkü sisteminizi bilmeden verilen her rakam tahmindir. Her yolda maliyeti ve süreyi artıran ya da azaltan etkenler şunlardır:

  • Büyüklük ve iç içelik: 3. bölümdeki envanterinizin gösterdiği gibi ekran, rapor ve ona bağlı diğer sistemlerin sayısı.
  • Kuralların netliği: onaylanmış her kural zaman kazandırır, bilinmeyen her kural geç ve pahalı bir keşif demektir.
  • Veri kalitesi: yinelenen ya da eksik veriler, yol hangisi olursa olsun, her taşımadan önce temizlenmelidir.
  • Çalışanlar için ne kadar şey değişiyor: olduğu gibi taşımak kullanıcı için hiçbir şeyi değiştirmez; değiştirmek neredeyse her şeyi değiştirir ve eğitim gerektirir.
  • Sistemi hâlâ kim anlıyor: geçmişini bilen tek bir çalışan haftalarca tahmin yürütmeyi önler.

Adımların sırası konusunda iki resmî kaynak tavsiye veriyor. Amazon'un kılavuzu yeniden mimari tasarımı en karmaşık ve en maliyetli strateji olarak tanımlar ve büyük geçişlerde önce taşımayı, taşıma tamamlandıktan sonra modernize etmeyi önerir. Microsoft'un Cloud Adoption Framework belgesi, olduğu gibi taşımanın yalnızca iş yükünün en az iki yıl mevcut hâlinde kalacağından eminseniz uygun olduğunu söyler; aksi hâlde işi iki kez yapmamak için hemen modernize etmek daha iyidir. Taşımanın kendisini buluta geçiş için pratik rehberimizde ele aldık.

Herkesin unuttuğu iki seçenek: tutmak ve emekliye ayırmak

Her eski sistemin şimdi modernize edilmesi gerekmez. Amazon'un ve Microsoft'un listeleri de tam bir proje maliyeti gerektirmeyen iki seçenekle başlar:

  • Emekliye ayırmak: bazı sistemler artık gerçekten kullanılmıyor. Amazon, son 90 günde hiç gelen bağlantı almamış ya da işlemci ve bellek kullanımı yüzde 5'in altında kalan uygulamaları örnek verir. Verilerini arşivledikten sonra bunları kapatmak bakımı ve güvenlik riskini azaltır.
  • Tutmak: işini yapan, yakın zamanda değişmesi için bir neden olmayan kararlı bir sistem ya da muadili olmayan bir fabrika makinesine bağlı bir sistem. Buradaki karar onu tutmak, izlemek ve daha sonra yeniden ele almaktır.

Hazır bir ERP ile değiştirmeye eğilimliyseniz önce hazır ve özel yazılımı ERP nasıl seçilir yazımızdaki ölçütlerle karşılaştırın ve onaylanmış kurallar listenizden başlayın: ürünün desteklemediği her kural ya pahalı bir uyarlamaya ya da elle yapılan işe dönüşür.

Origami'nin bakışı

Teknolojiden değil, kurallardan başlıyoruz: bu sistemdeki hangi iş kuralları şirketinizi farklı kılıyor, hangileri herkesle ortak? Sizi farklı kılan şey özenle kurulmayı ya da dönüştürülmeyi hak eder; ortak olan şeyi diğer sistemlerinizle iyi entegre edilmiş hazır bir ürün iyi karşılayabilir. Bu yüzden karar çoğu zaman bir karışımdır: bir sistem değiştirilir, bir diğeri dönüştürülür, üçüncüsü olduğu gibi tutulur.

Yapay zekâ araçlarını gerçekten zaman kazandırdıkları yerde, kodu okumada, dönüştürmede ve test etmede kullanıyoruz; ama yolu seçmek, her seçeneğin neyi koruduğunu ve neyi kaybettirdiğini gördükten sonra yönetimin kararı olarak kalır. Nasıl çalıştığımızı görmek isterseniz hizmetlerimize göz atın.

Bu haftanın alıştırması: her sistem için bir karar

Sistem envanterinize dönün ve her sistem için iki sütun ekleyin: kuralları şirketinize özgü mü, ortak mı? Sorun nerede: çalıştığı yerde mi, sistemin kendisinde mi? Ardından geçici yolu yazın:

SistemKurallar özgü mü, ortak mı?Sorun yerde mi, sistemde mi?Geçici yol
Örnek: fiyatlandırma sistemiÖzgüSistemdeDönüştürmek ya da yeniden kurmak
Örnek: izin yönetimiOrtakSistemdeHazır bir ürünle değiştirmek
Örnek: eski arşivKullanılmıyorFark etmezVerileri arşivledikten sonra emekliye ayırmak

Bunlar açıklayıcı örneklerdir; sizin tablonuz farklı olacaktır. Önemli olan, her sistemin yolu için yazılı bir gerekçesinin olması ve teklif istemeden önce süreç sahiplerince gözden geçirilmesidir.

Sırada ne var

Her sistem için bir yol seçtiniz. Projenin en riskli günü hâlâ önünüzde: geçiş günü. 6. bölümde yapay zekânın yazdığı ya da dönüştürdüğü kodu, iki sistemin aynı gerçek işlemlerdeki çıktılarını karşılaştırarak nasıl test edeceğinizi, ikisini belirli bir süre nasıl paralel çalıştıracağınızı ve ne zaman bir geri dönüş planına ihtiyaç duyacağınızı anlatıyoruz.

Kaynaklar