Bugün İş zekası projelerinin kullanımında gözönüne alınmayan yada kimi zaman özellikle gözardı edilen konuların başında development – test ortamlarının production (üretim) ortamından ayrılma ihtiyacı gelmektedir. Geçmişe nazaranla giderek artan kullanım potansiyeli ve farklı profiller nezdinde artık bu ihtiyaç eskiye nazaran daha fazla, lakin ufak bir hatanın dahi ciddi sorunlara yol açtığı aşikardır. Önceleri sadece büyük kurumsal veri ambarı projelerinde gündeme gelen bu konu artık veri ambarı bile olmaksızın raporlama analiz projelerinde zorunlu ihtiyaç olmaktadır. Bu noktanın gözardi edilmesindeki belirli başlı noktaları maddeleyecek olursak ;
* Test- development ihtiyacının öneminin anlaşılamaması
* Kurum içi kaynak yetersizliği (nedeniyle önemi bilinse dahi)
* Development-test ortamlarının sadece veri ambarları ile ilişkilendirilmesi
* İlave lisans gerektirmesi & maliyet kaygıları
Bugün İş zekası platformunun yöneticisi ve ilk aşamadaki geliştiricileri olan IT departmanları bu noktanın önemini iyi anlamak konumundalar. Özellikle iş zekası platformunda öne çıkan iş departmanlarının kendi raporlarını kendi yapmalarının istenmesi bu konunun önemini daha da ortaya çıkarmaktadır ki, ancak doğruluğu teyid edilmiş raporların üretim ortamına aktarılması gerekmektedir. Diğer yandan test-development ortamlarının uygulamaya geçirilmesi çok da komplike senaryolar değildir. BusinessObjects özelinde konuşacak olursak, ilk installation sonrasında test-development ve production repository’lerinin ayrılacak şekilde kurulumun ve tanımlamalarının yapılması yeterli olacaktır. Bunun üzerine kimlerin hangi yetkiler ile hangi repository’leri kullanabileceği ayarlandıktan sonra başarılı bir şekilde hayata geçirilebilir. Bu aşamada kaynak sıkıntısının olduğu senaryolarda aynı kaynakların development-test ortamlarını kullanan kişiler olması da sorunun çözebilecektir. Burada önemli olan ortamların ve prosedürlerin ayrılmasıdır, kişilerin veya mekanizmada yer alan kişilerin aynı olması sorun teşkil etmeyecektir. Life-Cycle-Management olarak adlandırılan bu çevrim veri ambarı projelerine kurumsal ve proje mantığı ile bakan kurumların gözönüne aldığı bir kavramdır. Keza bu ortamların donanımsal olarak da ayrılması diğer yandan fail-over içinde önemli bir avantaj yaratırken, veri entegrasyonunun dahil olduğu projeler de uçtan uçtan bir etki analizinin yapılabilmesi için bir altyapı oluşturacaktır.
Lisanslama konusundaki kaygılar ise , ilk baştan ele alındığında gerçekten düşünüldüğünün ötesinde gereksizdir. BusinessObjects özelinde yine ele alındığında, BusinessObjects belirli limitasyonlar nezdinde development-test lisansları için çok özel indirimler sağlamaktadır, mevcut durumda (%50 ye varan düzeydedir) Fakat bunun yanında named(kullanıcı bazlı) user bazında lisanslanan BusinessObjects yazılımlarında örneğin var olan lisanslardan bir adet development, bir adet test ortamına aktarılacak şekilde dahi bir ortam hayata geçirilebilir. Tabi bu noktada projenin büyüklüğü çerçevesinde ortamdaki geliştirici ve test eden sayılar önem kazanacaktır, fakat birer kullanıcılı ile dahi ortamların ayrılması çok avantaj teşkil edecektir. BusinessObjects yazılımlarının bir çoğunda development-test lisansları mevcut olmakla beraber, olmayan bazı modüllerde söz konusudur. Development ve test lisanslarının nispeten maliyet doğurduğu asıl projeler veri ambarı projelerindeki veri entegrasytonu yani ETL süreçlerindeki ayrımdır. Genelde çoklu kullanıcılarla geliştirilen ETL süreçlerinin bir proje yönetimi çerçevesince check-in check-out mekanizması ile denetlenebildiği ve kontrol altına alınabildiği ortam development-test ortamları ile production ETL süreçlerinin ayrılması ile mümkün olmaktadır, böylelikle ETL süreçleri üzerine çalışan tüm proje ekibi birbirlerinin yaptıklarını ezmeden bilakis sistemin denetim mekanizması ile projenin ortam amacı çerçevesince farklı komponent veya konu alanlarını sonradan kolayca birleştirmek üzere yönlendirilmektedir. Yapılan hataların kolayca yakalanması, yeniden kullanılabilir ETL prosesleri vb. bu noktadaki avantajlardan yararlanabilmek için development-test ortamının isansları kaçınılmaz hale getirmektedir (ETL süreçleri kullanıcı bazlıdan öte veri prosesine dair CPU bazlı bir lisanslama ile uygulanmaktadır) Bu noktada sağlanan katma değer, ödenen rakamdan çok dafa fazla olduğu malesef projelerin genelde ilerleyen süreçlerinde ortaya çıkmaktadır. Günümüzde büyük veri ambarı projelerinde dahi bu noktanın önemi atlanmakta veya manuel süreçler ile hataya açık şekilde hayata geçirilmektedir.
Development-test süreçleri ile ilgili daha fazla bilgi için lütfen sorularınızı göndermekten çekinmeyiniz
* Test- development ihtiyacının öneminin anlaşılamaması
* Kurum içi kaynak yetersizliği (nedeniyle önemi bilinse dahi)
* Development-test ortamlarının sadece veri ambarları ile ilişkilendirilmesi
* İlave lisans gerektirmesi & maliyet kaygıları
Bugün İş zekası platformunun yöneticisi ve ilk aşamadaki geliştiricileri olan IT departmanları bu noktanın önemini iyi anlamak konumundalar. Özellikle iş zekası platformunda öne çıkan iş departmanlarının kendi raporlarını kendi yapmalarının istenmesi bu konunun önemini daha da ortaya çıkarmaktadır ki, ancak doğruluğu teyid edilmiş raporların üretim ortamına aktarılması gerekmektedir. Diğer yandan test-development ortamlarının uygulamaya geçirilmesi çok da komplike senaryolar değildir. BusinessObjects özelinde konuşacak olursak, ilk installation sonrasında test-development ve production repository’lerinin ayrılacak şekilde kurulumun ve tanımlamalarının yapılması yeterli olacaktır. Bunun üzerine kimlerin hangi yetkiler ile hangi repository’leri kullanabileceği ayarlandıktan sonra başarılı bir şekilde hayata geçirilebilir. Bu aşamada kaynak sıkıntısının olduğu senaryolarda aynı kaynakların development-test ortamlarını kullanan kişiler olması da sorunun çözebilecektir. Burada önemli olan ortamların ve prosedürlerin ayrılmasıdır, kişilerin veya mekanizmada yer alan kişilerin aynı olması sorun teşkil etmeyecektir. Life-Cycle-Management olarak adlandırılan bu çevrim veri ambarı projelerine kurumsal ve proje mantığı ile bakan kurumların gözönüne aldığı bir kavramdır. Keza bu ortamların donanımsal olarak da ayrılması diğer yandan fail-over içinde önemli bir avantaj yaratırken, veri entegrasyonunun dahil olduğu projeler de uçtan uçtan bir etki analizinin yapılabilmesi için bir altyapı oluşturacaktır.
Lisanslama konusundaki kaygılar ise , ilk baştan ele alındığında gerçekten düşünüldüğünün ötesinde gereksizdir. BusinessObjects özelinde yine ele alındığında, BusinessObjects belirli limitasyonlar nezdinde development-test lisansları için çok özel indirimler sağlamaktadır, mevcut durumda (%50 ye varan düzeydedir) Fakat bunun yanında named(kullanıcı bazlı) user bazında lisanslanan BusinessObjects yazılımlarında örneğin var olan lisanslardan bir adet development, bir adet test ortamına aktarılacak şekilde dahi bir ortam hayata geçirilebilir. Tabi bu noktada projenin büyüklüğü çerçevesinde ortamdaki geliştirici ve test eden sayılar önem kazanacaktır, fakat birer kullanıcılı ile dahi ortamların ayrılması çok avantaj teşkil edecektir. BusinessObjects yazılımlarının bir çoğunda development-test lisansları mevcut olmakla beraber, olmayan bazı modüllerde söz konusudur. Development ve test lisanslarının nispeten maliyet doğurduğu asıl projeler veri ambarı projelerindeki veri entegrasytonu yani ETL süreçlerindeki ayrımdır. Genelde çoklu kullanıcılarla geliştirilen ETL süreçlerinin bir proje yönetimi çerçevesince check-in check-out mekanizması ile denetlenebildiği ve kontrol altına alınabildiği ortam development-test ortamları ile production ETL süreçlerinin ayrılması ile mümkün olmaktadır, böylelikle ETL süreçleri üzerine çalışan tüm proje ekibi birbirlerinin yaptıklarını ezmeden bilakis sistemin denetim mekanizması ile projenin ortam amacı çerçevesince farklı komponent veya konu alanlarını sonradan kolayca birleştirmek üzere yönlendirilmektedir. Yapılan hataların kolayca yakalanması, yeniden kullanılabilir ETL prosesleri vb. bu noktadaki avantajlardan yararlanabilmek için development-test ortamının isansları kaçınılmaz hale getirmektedir (ETL süreçleri kullanıcı bazlıdan öte veri prosesine dair CPU bazlı bir lisanslama ile uygulanmaktadır) Bu noktada sağlanan katma değer, ödenen rakamdan çok dafa fazla olduğu malesef projelerin genelde ilerleyen süreçlerinde ortaya çıkmaktadır. Günümüzde büyük veri ambarı projelerinde dahi bu noktanın önemi atlanmakta veya manuel süreçler ile hataya açık şekilde hayata geçirilmektedir.
Development-test süreçleri ile ilgili daha fazla bilgi için lütfen sorularınızı göndermekten çekinmeyiniz
Hiç yorum yok:
Yorum Gönder