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.
Hiç yorum yok:
Yorum Gönder