Özet. Alt yapısını Bilgi Teknolojilerinin oluşturduğu, yazılım, donanım veya ikisini birlikte barındıran bütünleşik sistemlerin yaygın şekilde kullanıldığı ortamlarda yenilenen ve büyük bir hızda değişiklik gösteren teknolojik gelişmeler, var olan sistemlerin eski, atıl ve yetersiz kalmasına sebep olmaktadır. Bu da organizasyonların mevcut yapılarını yeni yapılara ayak uyduracak şekilde değiştirmelerini gerekli kılmaktadır. Sadece teknolojik gelişmeler değil, aynı zamanda organizasyonların ihtiyaçlarının değişmesi ve yapılarının büyümesiyle de bu tür bir gereksinim doğabilmektedir. Bu durumda da yeni taleplere ve değişikliklere yetmeyen mevcut sistemlerin (yazılım, donanım ve bütünleşik olarak) değişikliği zorunlu olmaktadır. Bu bildiride, yaklaşık 350 şubesi bulunan bir katılım bankasında, büyük bir dönüşüm süreci içinde yeni kurulmuş olan BOA (Business Oriented Architecture) alt yapısında geliştirilen bir ERP (Enterprise Resource Planning) modülünün dönüşümünde kullanılan Paralel Uyum Süreci ile Çek Teminat İşlemlerine ait bir modülün dönüşümünde kullanılan Big Bang Uyum Süreci kıyaslanmıştır. Kıyaslama bize iki yöntemin de avantaj ve dezavantajlarına bakıldığında Big Bang Uyum Sürecinin daha tercih edilebilir olduğunu göstermektedir. Zaman ve insan kaynaklarının verimli kullanılması ve dönüşüm zamanı koşullarının çeşitliliği uyum süreci tercihinde her zaman göz önünde bulundurulmalıdır.
Giriş
Genel olarak Uyum Süreci’nin 3 değişik formu mevcuttur: Big Bang Uyum Süreci Paralel Uyum Süreci Fazlandırılmış Uyum Süreci
Bu süreçler Yazılım, Donanım ve Verileri de içeren tüm bir sistem şekliyle ele alınabildiği gibi, bu makalemizde biz sadece Yazılım ve Veriyi içeren kısmını irdeleyeceğiz. 1.1
Bu süreç eski ile yeni sistem arasında hızlı bir değişim ve veri taşımasını sağlayan bir süreçtir. Tüm fonksiyonlarıyla yeni sistem belirli bir tarihte gerçekleştirilir ve eski sistem ile yeni sistem arasında bir bağ bulunmamaktadır. Bu yüzden bünyesinde bazı riskleri barındırır: 1. Organizasyon değişim için hazır olmayabilir (Kullanıcı ara yüzü ve iş mantığı değişiklikleri), 2. Yanlış veri kümesi kullanılmış olabilir, 3. Başlatma problemleri ve tecrübe eksikliği gibi nedenlerle bilgi sistemi çıkmaza girebilir, 4. Yeni sistemin canlı ortama geçişi için eski sistemin kapalı bulunması ki bunu aşağıdaki alt durumlarla açabiliriz: (a) Müşteri gibi 3. Paydaşların sistem değişikliğinden etkilenmemesi için hafta sonu veya resmi tatil günleri gibi özellikle işlemlerin çalışmadığı bir zaman diliminin seçilmesinin zorunluluğu, (Artık web dünyasında her işlem 7/24 çalıştırılabilme esasına dayalı yapıldığından bu zaman aralığı daha da daralmaktadır.) (b) Geçiş sürecinde dönüşümün ertelenmesi veya iptalinin gerektiği durumlarda eski sistemin tekrar ayağa kaldırılmasının maliyeti (Zaman - Veri kayıpları, süreç iptalleri vb.) 5. Yeni sistemin eskiyle genel olarak uyumluluğunun sağlanmaması sonucu, belirli bir süre yeni sistemin canlı ortamda kullanımından sonra eski sisteme dönüşün mümkün olmaması ya da maliyetinin çok büyük olması (Yeni sistemde parametrik tanımlamaların farklı yapılmış olması ve eskiye dönüşte eşleştirme ihtiyacının doğması vb.) 1.2
Bu süreç yeni sistemin canlı ortamda başarıyla kabul görmesi sürecine kadar yeni sistem ile eski sistemin birlikte yaşatıldığı ve iki sistem arasında Coexistence (Bundan sonra Eş Yaşam olarak isimlendirilecektir) denilen kültürün oluştuğu bir süreçtir. Big Bang Uyum Sürecindeki çoğu risk burada bertaraf edilmiştir. Ancak Big Bang Süreci’ne göre daha uzun ve maliyetli olması tercih edilebilirliğini azaltmaktadır. Bazı risklerini şöyle sıralayabiliriz: 1. Yüksek maliyetlidir, 2. Eski ile yeni sistemin yaşatılması gerekliliğinden dolayı kaynakların (Zaman, Personel vb.) verimsiz kullanılmasına neden olur, 3. Sürecin tamamlanması daha uzun sürer, 4. Verilerin eski ile yeni sistem arasında geçerlilik kontrolüne sebep olur, 5. Yeni sistemin giderlerine eski sistemin giderleri de eklenir (Bakım, Ek Geliştirme vb.) 6. Eski ile yeni sistem arasında bağımlılık oluşur. Bu bağımlılıktan ötürü; (a) Yeni sistem eski sistemin kısıtlarıyla dizayn edilmek zorunda kalınır, (b) Eski veya yeni sistemde yapılacak değişikliklerin iki tarafa yansıtılması sorunu doğar, (c) Eski sistemin kapatılması için ekstra zaman ve personel kaynağı ayırmak gerekir. 1.3
Bu süreç büyük bir sistem veya uygulamanın modül, iş odaklı veya coğrafik olarak fazlara bölünüp aşama aşama geçişin sağlandığı bir süreçtir. Fazlara ayırmanın temelde işleri yönetmede kolaylaştırdığı söylense de sürecin uzaması ve modüller arası entegrasyonun düzgün kurulması ve bağımlılıkların azaltılması önem arz etmektedir. Bu sürecin de bazı riskleri şu şekildedir: 1. Odaklanma ve aciliyet bu süreçte yoktur, 2. Geliştirmeler geniş bir zamana yayılarak devam etmektedir, 3. Diğer modullerdeki verilere duyulan ihtiyaçtan dolayı bilgi kaybı söz konusudur, 4. Bazı ekstra ayarlamalara gereksinim duyulur, 5. Her fazın birbirinden bağımsız hayata geçirilmesinden dolayı eski sisteme dönüş daha zordur, 6. Eski sistem ile yeni sistem arasında geçici bağlantılar kurulması gerekir ve bu da eski sistem bağımlılığının getirdiği tüm riskleri barındırır. 2
Kıyaslama için iki farklı yazılım projesi seçilmesine rağmen genel yazılım geliştirme süreçlerindeki temel parametrelere haiz olmaları ve odak noktalarının süreçlere uyarlanabilmesi kıyas yapmamızı mümkün kılmıştır. 2.1
ERP dönüşüm sürecinde eski ile yeni sistemin özet verileri aşağıda sunulmuştur:
Oracle Web 2 katmanlı 16 48 48 İşlemlerin kayıt edildiği bir tablodan 5 dakikada bir sırayla okuma yaparak veri tabanı işlemlerini gerçekleştiren yeni bir Windows Service uygulaması yazıldı.
MS SQL Masaüstü (WPF) 3 katmanlı 16 48 1 69
MS SQL üzerinde Service Broker yapısı kurularak Windows Service uygulaması yazıldı.
Tablo 1. Tabloda ERP Dönüşüm Sürecinde Eski Sistem ve Yeni Sistem verileri bulunmaktadır. Proje süresi toplamda yaklaşık 211 adam/gün sürmüştür. Bu sürecin asıl dönüşüm kısmı 143 adam/gün tutarken, Paralel Uyum için kurulan Eş Yaşam yapısı için de ekstradan 68 adam/gün harcanmıştır. Sistem hala Eş Yaşam yapısı üzerinden koşturulduğundan sistemde yapılan değişiklikler için harcanan süre Eş Yaşam yapısına yapılacak olan müdahalelerle birlikte yarısı kadar artmaktadır. Eş Yaşam yapısının ayrıca sistemde kaynak tüketimine olan olumsuz sonuçları da (veri tabanı sorgulama, güncelleme ve kayıt işlemleri, iki taraflı kayıtların sıralı aktarımı için kullanılan sistemlerin işletilmesi ve bakımı vb.) dikkate alındığında projenin asıl maliyetinin gereksiz yere arttığı gözlemlenebilmektedir. Burada kısaca bahsettiğimiz durumu basit örneklerle açmamız gerekirse; 1. Eski veya Yeni sistem üzerinde tablolara ek bir alan eklenmesi, tiplerin değiştirilmesi vb. durumlarda bu işlemin sadece eski ve yeni sistemlerdeki saklı yordamlarda (Kayıt, Güncelleme, Silme) yapılması yeterli olmayacak aynı zamanda Eş Yaşam için kullanılan saklı yordamlarda da aynı işlemlerin gerçekleştirilmesi gerekecektir. 2. İşlem sırası bekleyen veri tabanı işlemlerinin doğru sırada yapılması için kurulan alt yapının veri tabanı yönetim sistemi kaynaklarını verimsiz kullandığı ve kaynak yükünü artırdığı gözlemlenmiştir. 3. Normal ekran geliştirmelerinde Eş Yaşam için kurulan triggerların (tetikleyicilerin) tüm gelişim süreci ortamlarında (Development, Test, Pre-Production, Production) doğru çalıştırılmasının sağlanması, burada yaşanacak herhangi bir engelin çözümü için de Eş Yaşam sistemini kuran personelin tecrübelerinin yeni sistemde geliştirmelere devam eden personellere aktarımının sağlanması gerekmektedir. Ya da sistemi kuran personellerin bu sistemin kapatılmasına kadar bakım kaynağı olarak kullanılması ve iş yüklerinin arttırılması da bir seçenektir. Ancak iki seçim sonucunda da zamanın verimli kullanılamadığı açıktır. 2.2 Bu dönüşüm sürecinde eski ile yeni sistemin özet verileri aşağıda sunulmuştur:
Eski Sistem Yeni Sistem Veri Tabanı MS SQL MS SQL UI Arayüzü Masaüstü Masaüstü (WPF) (WindowsForms) Mimari 2 katmanlı 3 katmanlı Ana Tablo Sayısı 4 5 Ana Saklı Yordam Sayısı 7 10 Tablo 2. Tabloda Çeklerin Teminata Alınma Dönüşüm Sürecinde Eski Sistem ve Yeni Sistem verileri bulunmaktadır.
Dönüşüm aşamasında verilerin yeni sisteme aktarılması işlemi yaklaşık 1 adam/gün sürmüştür. Projenin geliştirme süreci de yaklaşık 27 adam/gün sürmüştür. ERP dönüşüm sürecindeki gibi Paralel Uyum Süreci ile ekstra bir gelişim yapılmış olsaydı bu süre en az 13 adam/gün daha uzamış olacaktı. Dolayısıyla normalde 27 adam/gün de biten proje 40 adam/gün sonra ancak tamamlanabilecekti.
Bu uyum sürecinin tek riski sistemin düzgün çalışmaması olasılığı ki bunu zaten Development, Test ve PreProduction ortamlarında sırasıyla Yazılımcı, Analist, Testçi ve Son Kullanıcı testleriyle 0 (Sıfır) hataya yaklaştırarak minimize ediyoruz. Dolayısıyla Yazılım Geliştirme Süreçlerini düzgün işlettiğimiz zaman tanım kısmında bahsettiğimiz risklerle karşılaşmamız için bir sebep kalmamaktadır ki bu risklerin büyük bir kısmı diğer uyum süreçlerinin genelinde bulunmaktadır.
Yazılım Geliştirme Sürecinde genel risklerden hangilerinin elendiğini aşağıda şu şekilde sıralayabiliriz: 1. Organizasyon değişim için hazır olmayabilir (Kullanıcı ara yüzü ve iş mantığı değişiklikleri): PreProduction ortamında Son Kullanıcı Testi yaptırılarak bu risk ortadan kaldırılabilmektedir. 2. Yanlış veri kümesi kullanılmış olabilir: Yanlış veri kümesi canlı ortam öncesi günlük olarak gerçek verilerle ezilen PreProduction ortamında gözlemlenerek doğru verilere dönüştürülmesi veya bu verilerin bir şekilde kapsam dışına alınması sağlanarak bu risk ortadan kaldırılabilmektedir. 3. Başlatma problemleri ve tecrübe eksikliği gibi nedenlerle bilgi sistemi çıkmaza girebilir: b. Maddesindeki canlı ortam öncesi geliştirme ortamı sayesinde bu risk ortadan kaldırılabilmektedir. Genel risklerden elenemeyenler: 4. Yeni sistemin canlı ortama geçişi için eski sistemin kapalı bulunması: Bu risk için fazla alınabilecek bir önlem yok. Çünkü reel dünyada iletişim araçlarının bu denli gelişmiş olması kullanıcı makine arasındaki bağı kopmaz ve sürekli bir hale getirmekte. Bundan dolayı da 7/24 esasına dayalı bir uygulama erişimi söz konusu olmaktadır. Sistemlerin canlıya alınması bu yüzden daha zahmetli ve dikkat edilmesi gereken bir yapı halini almaktadır. Burada sanal sunucuların ve ortamların eş zamanlı hazır hale getirilmesinin avantajları kullanılarak bu risk minimize edilebilir. Bu verilen örnekte eski günlük çalışan SQL Joblarının, yetkilendirmelerin kapatılması periyodik canlıya geçiş süreci içinde akşam vaktinde mesai saati dışında yapılmış ve kullanıcılar gerekli bilgilendirmeler kendilerine yapılmış olduğundan ertesi gün yeni uygulama üzerinden işlemlerine devam edebilmişlerdir. Farklı senaryolar için bakım kapsamında sistemin uzun süre kapatılması ihtiyacı bu senaryoda doğmamıştır. 5. Yeni sistemin eskiyle genel olarak uyumluluğunun sağlanmaması sonucu, belirli bir süre yeni sistemin canlı ortamda kullanımından sonra eski sisteme dönüşün mümkün olmaması ya da maliyetinin çok büyük olması: Bu süreçte eski sistem ile yeni sistem arasında bir ilgileşim kurulmadığından dolayı yeni sistemden eski sisteme dönüş mümkün ancak geri dönüş senaryolarının önceden oluşturulmuş ve kapsam içinde hazır bulunduruluyor olması gerekir. Eğer böyle bir senaryo üretilmemişse geri dönüş sancılı ve sıkıntılı olacaktır. Bu örnekte böyle bir durumla karşı karşıya kalınmadığı için geçiş sorunsuz bir şekilde tamamlanmıştır. 3
Teknolojik yenilikler, sistemlerin ve uygulamaların süreğen bir şekilde aynı seviyede ve aynı yeterlilikte hizmet sağlamasını engellemektedir. Bu yenilikler sistemlerde ve uygulamalarda yeni geliştirmeleri zorunlu kılmaktadır. Ayrıca kural koyucuların getirdiği zorunluluklar, yeni ürün ve portföy olanaklarının sisteme dahil edilmesi, sistemler arası entegrasyonlar da bunlara katalizör etki yapmaktadır.
Uyum süreçleri temelde 3 ana başlık altında gerçekleştirilmektedir. Bunlar, Big Bang Uyum Süreci, Paralel Uyum Süreci ve Fazlandırılmış Uyum Süreci. Bu süreçlerin birbirilerine nazaran getiri ve götürüleri mevcuttur. Zaman, personel ve maliyet kaynakları açısından en doğru süreci bulmak için kurulacak olan yeni sistemin teknik alt yapısının, geliştirme yapılan alanların ve teknik personel yetkinliklerinin doğru analiz edilmesi gerekmektedir.
Bu çalışmada, var olan ve hali hazırda kullanılan iki ayrı sistemin, Big Bang Uyum Süreci ve Paralel Uyum Süreci kullanılarak yeni sisteme geçişinin kıyaslaması yapılmıştır. Her ne kadar Big Bang Uyum Süreci Paralel Uyum Süreci’ne nazaran daha riskli gözükse de, kullanılan Yazılım Geliştirme Süreci baz alındığında bu tür risklerin doğal olarak kendiliğinden elendiği gözlemlenecektir.
Hızlı üretim çılgınlığı ve hızlı adaptasyonların yaşandığı günümüz çağında, üretim bandının sadeleştirilerek, daha karmaşık sistemlerden yalın ve tekrar kullanılabilir sistemlerin inşasına geçiş önem arz etmektedir. Bundan dolayı sistemlerin yenilenmesinde var olan alt yapıların değiştirilmesi aşamasında daha az sorun yaşamak için modüler sistemlerin kurulması, değişikliğin kuruma veya şirkete daha az maliyet doğuracak senaryoların tercih edilmesi sağlanmalıdır.
Bu çalışmayla da gördük ki, Big Bang Uyum Süreci diğerlerine nazaran risklerine rağmen zaman ve personel anlamında kaynakların daha verimli kullanıldığı bir süreçtir. Paralel veya Fazlandırılmış Uyum Süreçlerinin de tercih edilebilirliği yüksek senaryoların oluşması muhtemel ise de Big Bang Uyum Süreci her halükarda en iyi çözüm olarak karşımızda durmaktadır.