Türkiye’de Kurumsal Mimarinin Gelişimi ve Organizasyon Yapıları

Türkiye’de Kurumsal Mimari konusunda son 7-8 yıldır bir hareketlenme var. Bu hareketliliğin bir kaç nedeni olduğunu düşünüyorum:

• Türkiye’deki IT şirketleri organizasyonel yapılarını yabancı danışmanlık şirketleriyle beraber geliştirme alışkanlığı kazandılar. Yabancı şirketler de organizasyonel yapılara mutlaka “Architecture “ ekipleri koyuyorlar. 
• Legacy (mainframe) sistemlerden açık sistemlere ve SOA mimarisine ve çok katmanlı yapılara geçiş. Bu iş başlı başına bir yazı konusu.  Legacy sistemlerde işletim sistemi, uygulama geliştirme ortamı, veritabanı  kısacası herşey bir arada olduğu için daha derli toplu bir yapı var. Oysa açık sistemlerde uygulama geliştirmenin etkin ve verimli olması için mutlaka belirli kurallara, politikalara ve standartlara göre yapılması gerekiyor. Sadece uygulama geliştirme tarafında değil altyapı tarafında da standart ve politikaları belirleme ve uygulama ihtiyacı bulunmakta. Özellikle satın almalarda bu standartların ve politikaların uygulanması çok büyük önem kazanmaktadır.
• Türkiye’de  TOGAF, Business Process Modelling araçları, EA araçları konularında eğitim ve danışmanlık veren firmalar aktif bir şekilde  çalışmaya başlamıştır. Gartner, Opengroup  Türkiye  vb. kuruluşlar değişik seviyelerde bilinci artırmak için ciddi çaba harcamakta, etkinlikler düzenlemektedir.

Türkiye’deki mimari ekipler ne yapıyorlar, nasıl yapılanıyorlar?

Mimari Takım	Görevi/Fonksiyonu
İş mimarisi ekipleri (Business architecture)	İş süreçlerini (process) ve yeteneklerini (capability) tasarlayan ve modelleyen ekipler; genelde Bilişim Teknolojileri departmanında yer almıyor.  Genelde Business Process Reengineering adı altında faaliyetlerini devam ettiriyorlar. .
Teknoloji(altyapı) mimarisi ekipleri (Technology architecture)	Altyapı sistemlerine ait modelleri çizen, standartları kuralları belirleyen, projelere bu anlamda dahil olan ve gelecek mimariyi belirleyen ekipler olarak karşımıza çıkmakta. Bu ekipler genelde “Kurumsal Mimarı” departmanı altında değil daha çok altyapı ekiplerinin altında bir takım olarak konumlanmaktadır. Diğer birçok organizasyonda da bu fonksiyon kendiliğinden yürütülmekte, ayrı bir takım bile bulunmamaktadır. Altyapı ekiplerindeki kıdemli uzmanlar ve yöneticiler bu fonksiyonu sorumlulukların bir parçası olarak yerine getirmektedir ya da yerine getirmemektedir J
Veri mimarisi ekipleri (Data architecture)	Kurumsal Mimari deki en temel ekiplerdir. Buradaki varlıkları nerdeyse hiç sorgulanmıyor. Yaptıkları şey ise verinin uygulama geliştirme süreçleri içinde nasıl kullanılması gerektiği konusunda politikaları, standartları belirlemek,  verinin mantıksal seviyede modellenmesini sağlamak. Eğer yeteri kadar güçlüler ise veri kalitesi ve veri profilleme gibi çalışmaları gerçekleştirmek. Aslında bu konuda yapılacak daha çok şey var. Oracle ve IBM ‘in sunduğu proprietary endüstri modelleri ve best practice lar var. Verinin uygulama mimarisi üzerindeki rolü aslında bildiğimizden çok daha fazla..
Uygulama mimarisi ekipleri (Application architecture)	En civcivli yere geldik. Yeri konusunda sıkıntı yok, “Kurumsal Mimari” ekibi içinde. Ama ne yapacak ve bu bizim için değerli mi? ·         Uygulama mimarisi ekibinin en temel görevi  uygulama portföyünü oluşturmak ve güncel tutmak. Yani bizim uygulamalara ait bilgiler; hangi uygulamaları  kullanıyoruz, proje halinde  mi, teknolojisi ne sorumlular kimler vs. · Uygulamaların stratejisini belirlemek, emekliye ayrılacak uygulamaları belirlemek. Bunu yaparken olay ve problem yönetimi ile sözleşme yönetimi ve talep yönetimi  süreçlerini kullanmak.  ·   Uygulamaların hangi iş süreçlerinde kullanıldığını analiz etmek. Bu şekilde uygulamaların iş sürecini, etkin ve verimli bir şekilde kullanıp kullanmadığını anlamak. Örneğin; bir kullanıcı bir işi yapmak için 3-4 farklı uygulamaya giriyorsa mimar bunu farketmeli, sorunun veriden mi yoksa uygulamadan mı kaynaklandığını anlamalı, buna göre süreci “uygulama açısından” nasıl sadeleştirileceği konusunda fikir ortaya atmalı. Bir nevi süreç geliştirmeci gibi. · Uygulamaların performans izleme, yetkilendirme, loglama gibi ortak uygulamalara entegre olarak canlı ortamlara  çıkmasından emin olmak ·  Satın alınacak veya geliştirilecek uygulamaları uygulama mimarisi içinde konumlandırmak, diğer uygulamalarla entegrasyon noktalarını belirlemek. ·  Uygulama geliştirme projelerinde uygulamaları ve bunların arasındaki entegrasyonları servis/batch vs.) kavramsal/mantıksal olarak belirlemek. İşte civcivli kısım bu. SOA mimarisinde servis aslında business service anlamına geliyor. Dolayısıyla uygulamalar arasında servisleri belirken iş fonksiyonalitesine referans verecek şekilde servisleri tasarlamak lazım. Uygulama mimarları kavramsal/mantıksal olarak servisleri tasarlar da… Türkiye ‘de uygulama mimarisinden anlaşılan gerçekten geliştirilecek servisleri belirlemek ve bunların yaşam döngüsünü yönetmek. (SOA Governance) Yani bir sonraki satırda anlatılan “yazılım mimarisi”.
Yazılım mimarisi ekipleri (Software architecture)	Yeri konusunda sıkıntı olsa da çoğu zaman “Kurumsal Mimari” ekibi içinde. Bu ekipler ESB yi yönetiyor, SOA Governance yapıyor. Uygulama geliştirme tarafından kullanılan alt yapıyı ayakta tutuyor, ortak servislerin uygulama geliştirmesini yapıyor.  Dolayısıyla siz yazılım mimarisi fonksiyonu için bir uygulama mimarıyla iş görüşmesi yaptığınız zaman “az teknik” bulabilirsiniz. Şunu rahatlıkla söyleyebilirim. Yazılım mimarisinin fonksiyonu Türkiye de mimari açıdan çok iyi anlaşılmıştır. Bu yüzden iş olanakları açısından da oldukça çok fırsat vardır. Ancak organizasyonların Kurumsal Mimariyi sadece yazılım mimarisine indirgemeleri Kurumsal Mimarinin olası faydalarından yararlanamamalarına sebep olur.

(Tip sınıflandırması herhangi bir metodolojiye dayanmamaktadır, sadece kendi fikrimdir)

A tipi : Büyük kurumlardaki yapılanma. Kurumun Bilişim Teknolojileri departmanı altında  “Kurumsal mimari ya da Mimari” adı ile veri mimarisi, uygulama mimarisi ve yazılım mimarisi gibi takımlar bulunuyor.  İş mimarisi iş biriminde ve teknoloji mimarisi ekipleri  altyapı geliştirme ekiplerinde yer alıyor.

B tipi :  Orta ölçekli kurumlardaki yapılanma. Kurumun Bilişim Teknolojileri departmanı altında  “Kurumsal mimari ya da Mimari ve İş Zekası ya da Uygulama Altyapı” adı ile veri mimarisi, ve yazılım mimarisi gibi takımlar bulunuyor.  İş mimarisi, uygulama mimarisi  ve teknoloji mimarisi   yapılmıyor.

En son bahsedeceğim konu ise Domain Architect’ ler ve Solution Architect’ler. Domain Architect Kurumsal Mimari içinde değil daha çok uygulama geliştirme domainleri içinde bir şapka/rol olarak karşımıza çıkmaktadır.  Domain architect kendi domainindeki işi, uygulamaları, detay seviyede servisleri, tabloları, kişileri, yetkinlikleri, iş birimini en detaylı bilen kişidir. Uygulama mimarından bir “tık” daha fiziksel detaya sahiptir.  Dolayısıyla uygulama mimarı, veri mimarı, yazılım mimarı birden fazla domain architectle beraber çalışarak uygulama geliştirmemelerinden kaynaklanan bilgi eksiklerini kolaylıkla giderebilirler.

Solution Architect (Çözüm Mimarı)  ise daha çok alınacak third party yazılımları seçen, alındıktan sonra bunun çalışması için gereken tüm entegrasyonları belirleyen, bu entegrasyonları yapan/yaptıran/yöneten kısaca çalışır hale gelinceye kadar talep aşamasından proje teslimine kadar çalışan mimardır.  Bu rol/şapka daha çok kendi uygulamasını kendi geliştiren değil de third party yazılım alarak uygulama mimarisini geliştiren organizasyonlar için geçerlidir. Aynı kurumda hem uygulama mimarı, hem çözüm mimarı hem de yazılım mimari bulunmayacağı aşikardır.

Çok fazla mimari rol, organizasyon ve görev(fonksiyon) var gibi gözüküyor. Ancak şunu unutmamak lazım, Bilişim Teknolojileri’nin karmaşıklığını ancak bu şekilde değişik rollerdeki insanların deneyimleri, farklı bakış açıları ve düzenleyici katkılarıyla bertaraf edebiliriz.

Görüldüğü gibi aslında her mimari takım belirli bir fonksiyonu yerine getirmek için konumlanıyor. Dolayısıyla organizasyonlar ilk önce hangi mimari fonksiyonu yerine getireceklerine karar verip daha sonra uygun yetkinlikte personeli istihdam etmelidirler.

Kurumsal mimarinin ne kadar da kendine has framework ü ve teorisi olsa da şunu unutmamak gerekir. Tüm mimari çalışmalar organizasyona “değer katmak” üzerine planlanmalı ve bu “katma değer” tüm organizasyon tarafından üzerinde uzlaşılan bir “katma değer” olmalıdır. Tüm organizasyon olmasa bile en azından Bilişim Teknolojileri Üst Düzey Yöneticileri aynı düzlemde olmalıdır. Bu sağlanamazsa “Kurumsal Mimari” fonksiyon asla beklenen başarıya ulaşamaz.  

Son bir söz: Kurumsal mimarın arkasındaki gerçek itici güç CIO dur. CIO koşmak ve durup düşünmek isteyenler arasındaki dengeyi sağlayandır. Evet BT operasyonunu hızlı bir şekilde yürütmeliyiz ama performans, güvenlik, regülasyonlara uyum ve öngörülemeyen gereksinimler yüzünden kısa sürede kullanılmaz hale gelecek sistemler de geliştirmemeliyiz.