Yaşlanan yazılım uygulamaları için genellikle yazılım dünyası insanları olarak “Legacy” tabirini kullanırız bildiğiniz gibi. Biraz daha net anlamı anlamak için; “Günün şartlarına uymayan uygulamalar ve çözümlere “Legacy” uygulamalar diyoruz” diyebilirim. 10 yıl önce, hatta daha da önce geliştirilen ve hala kullanılan, ama artık negatif yönlerinin ağır bastığı, belli ihtiyaçları karşılamasının zor olduğu “Legacy” uygulamalar eminim bir çok kişinin karşısına çıkıyordur.

“Legacy” uygulamalar günün şartlarına uymamaları, adaptasyon güçlükleri yaşatmalarından dolayı oldukça zorlayıcı uygulamalar olabilir. Günün şartlarına uymamaları derken, atıl kalan donanımlar, desteklenmeyen işletim sistemleri, veri saklama sistemleri, değişim ihtiyaçları, performans durumları, kullanım şekillerinin çeşitliliği vs. bir çok başlık sayabilirim ama şimdi bunlara girmiyoruz.

Windows NT’den nerelere geldik 🙂

Windows NT üzerinde çalışan, PHP 3.0 ile geliştirilmiş, WEB bileşenleri sadece Internet Explorer’da düzgün çalışan, RDBMS olarak SQL Server 7.0 kullanan bir uygulamanın günümüzde hala yoğun bir şekilde kullanıldığını düşünün…Günümüze gelene kadar alt yapı olarak geliştirmelerin ve upgrade’lerin riskleri, iş ihtiyaçlarının en önemli olduğu algısı ve en önemlisi de insan faktörü yüzünden uygulama bu zamanın şartlarına uymayan bir çözüm olarak karşımızda…

Çok uç bileşenler ile bir örnekleri oldu ama benzer senaryolar var.

Bu tarz uygulamalar ne kadar zorlayıcı da olsa, günün IT çalışanları tarafından “offf poff” şeklinde yaklaşılıp, ne kadar çok negatif şey söylense de (bu arada hepsi genelde doğrudur), unutulmaması gereken çok önemli bir nokta var; “Değer”.

“Legacy” dediğimiz uygulamalar, sistemler öyle önemli bir değer yaratmışlar ki hala günümüze denk yaşayabilmişlerdir demek ki. 10, 15, 20 yıldır ayakta olan uygulamaları düşünün; ilk kullanıldıkları dönemlerden beri insanlara ve belli iş modellerine o kadar çok değer katıyorlar ki, hala o değeri koruma mücadelesinde içindeler… Biraz daha toparlamak gerekirse “Legacy” diye adlandırdığımız uygulamalar, ne kadar çok negatif bileşenle günümüze gelse de sahip oldukları “değer” çok önemlidir… Ve bu değer uygulamaların en güçlü özelliğidir.

Bir uygulamanın “Legacy” olarak adlandırılmaması, 10 yıl sonra da günün ihtiyaçlarını kolaylıkla karşılayabilmesi, bir 10 yıl sonra kattığı değerin üstüne yeni değerleri koyabilmesi için neler yapılması lazım, nasıl geliştirilmesi lazım falan filan bunlardan şimdi bahsetmeyeceğim… Derya deniz konular çünkü…15-20 yıl önce bir uygulamayı değişime hazır bir şekilde geliştirmek, bulunduğu zamanın ihtiyaçlarına uygun geliştirmek pek mümkün değildi belki, ama günümüzdeki yaklaşımlar yazılımların ömürlerini biraz daha kaliteli kılmayı sağlıyor. Arada karalarım ama bir şeyler.

Şimdi önce “Legacy” uygulamaları günü şartlarına uygun bir şekilde nasıl dönüştürebiliriz ya da yakınlaştırabiliriz buna bakmaya çalışalım.(Yazının asıl konusuna, anca gelebildik…) Önce neden böyle bir dönüşüme ihtiyacımız var, sahip olunan değerleri günümüze taşımak neden önemli bunların farkındalığı, kararı ve bir stratejisinin olması çok önemli. Bunların gerçekten farkındaysak, iş modelimiz ile eşleşiyorsa o zaman dönüşümün anlamı ve motivasyonu daha yüksek olacaktır. Yoksa bazı teknolojik çözümler moda ve popüler kavramlar oldu diye tercih edilip, “Legacy” uygulamalar onların ışığında evrilirse, mevcut düğüm, kör düğüme dönüşür.

Dönüştürelim…

İlk olarak komple dönüştürme stratejisini ele alalım. “Legacy” uygulamanın yerine, yeni teknolojiler ve alt yapılar ile günün şartlarına uygun olacak şekilde bir dönüştürme; yani çözümü/uygulamayı baştan geliştirmeyi kastediyorum. Eğer şartlar ve mevcut iş modeli uygunsa (-ki çok az bir ihtimal), tüm uygulamayı ya da çözümü baştan ele almak bir çok kişinin büyük bir motivasyonla başladığı bir iş olacaktır. Burada ilerleme oldukça, “Legacy” uygulamanın dönüşümü değil de, yeni “değer” oluşturan bir çözümün ortaya çıktığı; komple yeni farklı bir uygulama ortaya çıkar. Aslında bu da tamamen doğaldır. Ama mevcut “Legacy” uygulamasının güçlü olduğu yönleri ve sahip olduğu değerler yansıtılmazsa, “Legacy” uygulama varlığını sürdürmeye devam eder, dönüşüm yerine orta vadede mitoz bölünme şeklinde üremiş yeni bir uygulamaya sahip oluruz.

İkinci olarak kademe kademe dönüştürmeyi düşünelim. Kademeli bir şekilde dönüşüm, belli açıdan riskleri azaltsa da, teknik olarak ortaya çıkartacağı zorluklar farklı olacaktır. Kademe kademe derken, “Legacy” uygulamayı belli parçalara bölüp, önce belli bir parçanın ele alınması, daha sonra diğer parçanın ele alınması şeklinde bir yaklaşımdan bahsediyorum. Hangi parçayı önce ele almak, parçalar arası bağlılık ve bağımlılıkları anlamak ve yönetmek de bu adımın en zor kısımlarından. Kademe kademe dönüştürme daha kontrollü olacağı için belli riskleri yönetmek daha kolay olacaktır. Bu tarz dönüştürmelerde sistemsel bileşenlerden başlamak her zaman en kolay olandır.

Bu iki strateji farklı noktalar ile evirilip, yeni stratejileri ortaya çıkarabilir. Ne yazık ki “Legacy” uygulamalar için kesin ve doğru bir yaklaşım yok. Uygulamanın riskleri, kattığı değerler, koruduğu değerler, negatif yanları ve artıları ile ele alıp ilerlemek en sağlam adımlar olacaktır. Nasıl bir strateji olursa olsun, günümüzün teknolojik avantajları ve bilgi birikimimizi kullanarak “Legacy” uygulamaların günün şartlarına adapte olmasını sağlamak için, ölçümleme, servis odaklı yaklaşım, soyutlama ve bulut platformlar mutlaka karşımıza çıkacaktır. Çıkmıyorsa bile, çözümün kapasitesi dahilinde bu konuları mutlaka ama mutlaka değerlendirmek gerekli.

Ölçümleme…

Ölçemediğimiz bir konuyu iyileştiremeyiz

İyileştirmek, geliştirmek istediğimiz tüm kavramlar için önce ölçüm yapabileceğimiz bir altyapımızın ya da sistemimizin olması gerekli. Hayattaki bir çok yaklaşım için geçerli bir durumdur. Ölçemediğimiz bir konuyu iyileştiremeyiz. Yazılım için de geçerli tabi ki. “Legacy” dediğimiz uygulama ve çözümleri günün şartlarına yakınlaştırmak için gerçekleştirdiğimiz strateji ve aksiyonlar için uygulamayı ölçebilmek çok önemli. En basitinden, uygulamanın kullanım yoğunluğu, en çok verdiği hata, en fazla yapılan işlem, en çok kaynak tüketen bileşen, en çok veri üreten özellik gibi bir çok benzer konuyu ölçebilmek durumda olmamız lazım. Bu ölçümlerden aldığımız değerler ile günün şartlarını kesiştirerek “Legacy” uygulamanın kattığı değerlere yön verilebilir. “Legacy” bir uygulamanın bir UI bileşeni hiç görüntülenmiyorsa yani hiç kullanılmıyorsa zaten doğal seleksiyonla sistemden çıktıysa, somut olarak da sistemde durmasına gerek yok. Bunun gibi değerlerinde farkına varılıp, hangi özelliklerin, günün şartlarına uygun duruma yaklaştırılması gerekir bunlarda ortaya çıkmış olur böylece.

Servis odaklı yaklaşım…

“Legacy” uygulamaların sahip olduğu önemli bir “değer” var diye yukarda bahsetmiştim. Bu “değerleri”, daha net bir şekilde ortaya çıkarmak gerekir ki, uygulamanın özellikleri, güçlü yanları daha tanımlı olabilsin. Günün şartlarına uygun hale getirirken, elimizde neler var bunları görebilelim. Bunları göstermenin en makul yolu, bu özellikleri “servis” olarak çıkarabilmek. 20 sene önce geliştirilen ve geliştirilmesi devam eden bir uygulamadaki bir özellik hala kullanılıyor diye düşünün. Uygulamayı da günün şartlarına dönüştürmek ihtiyacımız olsun. Bu özelliği baştan yazabiliriz, eğer 20 sene boyunca ki bilgiye tutarlı bir şekilde sahipsek, riskleri kabul ediyorsak ya da gerekli maliyetleri karşılayacak güce sahipsek falan filan…

Bunlar her zaman pek mümkün değil tabi ki, bu yüzden bu özellikleri, olduğu gibi(as-is) “servis” olarak dışarı sunabilmek, kapalı kutuyu bozmadan, kutunun içindekilere dışarıdan da erişebilmek, uygulamaların sahip olduğu “değerlerin” kullanılabilir olmasını sağlar. COBOL ile geliştirilen, yeşil siyah ekranlar ile sunulan bir özelliğin, temel fonksiyonları hiç değişmeden bir servis katmanı ile dışarı sunulabilmesi, o değerin günün ihtiyaçlarına uygun bir şekilde farklı yaklaşımlar ile de kullanılmasını sağlar. Tabi ki, temel olarak “Legacy” uygulama ortadan kalkmaz, kalkamaz. Ama kattığı değerler ortaya net bir şekilde çıkabileceği için, gerçekten kalkması gerekli mi, ya da yenilenmesi gerekli mi bunun farkındalığı olacaktır. Tekrardan geliştirilmesi gerekiyorsa da, baz modeli net bir şekilde elimizde olacaktır.

Soyutlamak…

Yazılım; soyut bir dünyanın, somut ihtiyaçları karşılama yöntemi şeklinde karşımıza çıkıyor malum. “Legacy” yazılımlar sahip oldukları bazı eski ya da güne uymayan bileşenler ile bizleri zorluyor. Bu bileşenlere olan bağımlılıklar çok derin olduğu zaman, günün şartlarına uygunluk da pek olmuyor. Bilgilerini Windows’un Event Viewer’ına yazan, IBM WebSphere MQ(v5.2)’ya bağlı olan bir uygulamanın direkt bu özellikleri yüzünden işletim sistemi ve Message Queue bileşenine bağımlılığı olmuş oluyor.

Bu tarz bağımlılıklar zaman içerisinde çeşitli versiyon yükseltmelerini ne yazık ki sağlayamıyor. Özellikle “Legacy” uygulamalarının yaşam alanları olan kurumsal ortamlarda bu daha mümkün. MS SQL Server’ın X versiyonuna Service Pack’i çıkmadan geçmeyen ya da X versiyonuna geçene kadar X+3 versiyonun çıktığı durumları eminim duymuşunuzdur. Bu arada bunların böyle olması, belli prosedür ve iş modellerinde mantıklı olabilir, kötü ya da yanlış diye söylemiyorum. Neyse… Bu tarz bağımlılıkları soyutlarsak, “Legacy” uygulamaları günün şartlarına daha yakınlaştırmak mümkün olabilir. Mesela az önceki senaryo üstünden gidecek olursak, uygulamanın çeşitli durum bilgilerini Event Viewer yerine daha genelleyici bir yaklaşımla dosyaya yazmak, Event Viewer yani işletim sistemi bağımlılığını kaldıracaktır. Aynı şekilde IBM WebSphere MQ yerine, message queue bileşeni soyutlandığında farklı MQ bileşenleri ile belli noktalar günün ihtiyaçlarını karşılayabilecek duruma gelir.

“Bulut” platformları…

“Bulut” platformlar…

“Bulut” bilişim kavramı, gelişen IT dünyasının hızına hız katan bir yaklaşım oldu. Bulut platformları, kompleks problemleri çok efektif bir şekilde çözümleyebilecek fırsatları, hızlı bir şekilde sunabiliyor. Altyapısal ihtiyaçlara çok kafa yormadan, iş modelleri ve yeni teknolojik değerleri üretmek oldukça kolay. Günün şartlarını sağlamayan “Legacy” uygulamalar için bu bağlamda oldukça güzel bir platform. “Legacy” uygulamaları, bulut platformlarına taşıyabilmek, uygulamaların direkt sınıf atlayabilmesi için güzel bir fırsat. Oradaki teknolojik destekler ve özellikler ile belki de uygulamada ki “Legacy” yaklaşımı kendiliğinden bile kaybolabilir. 15-20 yıl önce geliştirilen bir uygulamanın bulut platformlarına taşınması, uygun bir hale gelmesi tabi ki kolay değil. Ama çok da zor değil. Yukarda az önce bahsettiğim soyutlama yaklaşımı ve bulut platformların çeşitli özellikleri ile yapılmayacak bir durum yok. Özetle “Bulut” platformalar sadece günümüzün çözümleri için değil aynı zamanda “Legacy” uygulamalar için de çok ama çok önemli bir platform.

Özetle “Legacy” uygulamalar ayakta olduğu sürece, değer katmaya devam ettiği sürece IT dünyasında olacaklar. Bu dünyanın hızla değişen şartlarına bir şekilde uymak zorunda olacaklar. Yazılımcılar olarak bunları sağlamak da bizim işimiz. Yazdığımız, geliştirdiğimiz her uygulama da, hızla gelişen teknoloji ile bir gün “Legacy” sıfatını yiyecek. Şu an için 15-20 yıl önce yazılan uygulamalar için diyoruz belki, ama ileride de şimdi yazdığımız uygulamalar için 30-40 yıl sonraki günün şartlarında “Legacy” diyeceğiz.

İnsanoğlunun “yaşlanmak” gerçeğine, daha pozitif bir çağrışım yapsın diye genellikle “olgunlaşmak” ile yaklaşırım. Kendimi böyle kandırıyorum 🙂 Şaka bir yana bu yazılım çözümleri için de geçerli. Yaşlanan daha doğrusu olgunlaşan yazılımlar, zamanın gerçeğinden dolayı mutlaka olacak. Önemli olan olgunlaşma evresini çok uzun ve katma değer katan bir süreç olarak tutabilmek…