Kurumsal Mimari Aslında Ne, Ne Değil?

Aslında ortaya çıkan her kavram yaşanan bir takım sorunları çözmeye yönelik olarak geliştiriliyor. Bilişim Teknolojileri hem insan kaynağı hem de altyapı açısından çok maliyetli. Bu maliyetin etkin ve verimli bir şekilde kullanılması lazım. BT sistemleri büyüdükçe özellikle enterprise seviyede hangi uygulamanın hangi altyapının hangi iş sürecini nasıl desteklediği, sistemin hala ilk kuruluş amacına hizmet edip etmediği gibi bir çok konuda karmaşıklık yaşanıyor. Sadece kurumda çok uzun zaman çalışanlar her türlü bilgiye sahip olurken sonradan gelen üst düzey yöneticiler için bile visibility son derece düşük oluyor. Ahmet’e Mehmet’e sormadan kimse dirsek oynatamıyor. Çoğu kurumda ne işe yaradığı bilinmediği için kapatılamayan sunucular ve kullanıcı hesapları var.

Buna ilaveten her ekip BT sistemlerine kendi açısından bakıyor. İş tarafı sadece işi, rolü, süreci, ürünü biliyor, uygulama geliştirme sadece uygulamayı, yazılımı biliyor, altyapı tarafı da sadece sunucuları, networkü biliyor. Projelerde bütün bunların detayları ayrı ekipler tarafından gerçekleştirilse de;

• Yapılan işlerin üst seviyede birbiriyle tutarlılığının ve bütünlüğünün sağlanması
• Mevcut sistemlerle proje halinde olan sistemlerin(uygulamaların, altyapıların) standartlara uygun bir şekilde   entegrasyonu (hem uygulama hem altyapı seviyesinde)
• Güvenlik, performans(erişilebilirlik) standartlarına ve regülasyonlara uyumun sağlanması
• Projenin gelecek mimarilere uyumunun

ayrı bir fonksiyonalite olarak ele alınması ve yerine getirilmesi gerekiyor. Ben bu fonksiyona  Kurumsal Mimari diyorum. Kurumsal mimarinin kalbi ise esasında uygulamalar…. Altyapıcılar kızacak şimdi ama herhangi bir uygulamaya hizmet etmeyen altyapı hizmeti sanırım ki çok azdır.

Elimdeki sunumlara bakıyorum.  Kurumsal mimarinin amacı maliyet analizi ve etki analizi yapmak demişiz.  Bunları tekrar düşünelim:

Maliyet Analizi

Dönüp baktığımda bunlar biraz ikincil faydalar. Bir uygulamanın maliyetini bulmak için projelerle, operasyonel maliyetlerle eşleştirmeniz lazım. Bir veritabanı, bir sunucu üzerinde birden fazla uygulama varsa bunun lisans, elektrik, bakım maliyetlerini uygulamalara nasıl paylaştıracaksınız? Bunu kabaca yaparsanız çıkan sonuca güvenip kararlar alabilecek misiniz? Bu çok zor, zahmetli bir iş ve aslında Kurumsal Mimari’nin ana görevi değil. Böyle bir proje olursa Kurumsal Mimari aktif bir katılımcı olarak görev alır ama projenin sahibi değildir.

Etki Analizi

Etki analizi yapmak. Yani hangi iş süreçlerimiz hangi uygulamalarla onlar da hangi altyapı bileşenleriyle ilgili/ilişkili. Diğer bir deyişle hangi sunucuyu kapattığımızda hangi iş süreçleri etkileniyor? Bu bilgiye sahip olabileceğini düşünmek her duyanı etkiliyor. Özellikle ITIL süreçlerindeki değişiklik yönetimi için de çok önemli. Fakat pratiğe baktığınızda artık fiziksel sunucu kalmadı, çoğu sanalda. Dolayısıyla fiziksel olarak sunucuyu kapattığımızda ne oluyor sorusunu başka şekilde sormak gerekiyor. Peki bu ilişkilerin belirlenmesi ve tutulması önemli mi değil mi? Önemli. Peki ne için? Avaliability yi yani servis erişilebilirliği yönetebilmek için. Burada daha önemli hale gelen şey Servis Architecture konusu. SOA da yazılım seviyesindeki servisler değil bunlar. Daha üst seviyede BT nin iş birimlerine verdiği servisler, bunların karşılığı olan BT servisleri ve bunların ayakta durmasını sağlayan uygulama ve altyapı bileşenleri. Bu yapıları, Servis Kataloğu’ nu ve Kurumsal Mimarın bu konudaki rolünü daha ayrıntılı bir şekilde örneklerle paylaşacağım.