Türkiye’ de orta ve büyük ölçekli şirketlerin IT kanadında kurumsal mimari yapısının henüz hiç oluşturulmamış ya da bu adım atılmış olsa bile departmanlaşmanın tamamlanmamış olduğunu görmekteyiz. En fazla kullanılan organizasyon şeması tipi matrix organizasyon ve/veya nadir de olsa strong matrix organizasyon tipi olarak karşımıza çıkmakta. Bu organizasyon yapılarına göre; fonksiyonel yöneticiler ve altlarında varsa takım liderleri ve/veya ekibin tamamı yer almaktadır. Şirketler kurumsal mimari veya proje yönetim ofisi yapılarına gitmek yerine çoğu zaman fonksiyonel yöneticilerle paralel yetkilere sahip kurumsal mimar ya da proje yöneticileri almayı tercih ediyorlar. Uzunca bir dönemdir danışmanlık yapan biri olarak küçük/büyük firmalarda görüyorum ki bu seçim, tasarruf etmek için yapılıyor. Tabi teknolojiyi ve dünyayı yakından takip eden liderler yada yöneticiler, bu kısa vadeli tasarrufu yapmak yerine, EA departmanlarını hayata geçirmeyi veya PMO’ ları açmayı tercih ediyorlar. Çünkü bu yöntemin çok daha tasarruflu ve kaliteli bir yöntem olduğu artık tüm dünyada bilinmekte ve global tüm şirketlerde ( özellikle IT departmanları için ) uygulanmaktadır.
Şu anda bu yazıyı okuyan tüm kıdemli sistem yöneticileri, kıdemli yazılım mühendisleri ve middle level yöneticiler, bizler varken; kurumsal mimarlık departmanına ne gerek var, bu departmanın ya da şahıs olarak kurumsal mimarların ve bu departman içerisindeki kişilerin mühendis kadrolardan nitelik/eğitim olarak ne farkı var diye sorabilirler. İlk bakışta haklı bir soru tabi. Bu soruyu işin içinde olmadan önce ben de sormuştum. Hatta araştırmam ve kurumsal mimarlığa giden yolu seçmemde bu sorunun payının çok büyük olduğunu söyleyebilirim.
Enterprise Architecture departmanının, fonksiyonel departmanlara etkisini anlatmaya en belirgin farkla başlayalım : bir proje başlar ve biter, fakat enterprise architecutre ( kurumsal mimari ) sürekli devam eder. Bu yönüyle kurumsal mimariyi portfoy yönetimine biraz daha yaklaştırabiliriz. Ama yine de tam olarak değil. Çünkü portföyler de yıllık ya da uzun vadeli belirlenir. Enterprise architecture, şirket var olduğu sürece vardır. Fonksiyonel olarak oluşturulmuş bir ekibin yanında, nitelik olarak kurumsal mimariyi ayıran bir diğer faktör, fonksiyonel ekipteki her bir personelin kendine atanmış iş/işlerde çalışmasıdır. Örneğin yazılım geliştirme ekibine dahil olmuş bir software architect veya mühendis; elindeki geliştirmeyi en iyi şekilde yapmakla ve projelerin iyileştirmesiyle, atandığı projelere ait raporlamalarını yapmakla sorumludur. Kendisine verilen diğer kayıt dışı yetkileri ve işleri saymıyorum.. İlgili birimin teknik yöneticisi bu işi kontrol etmekle ve ekibinin yetemediği noktada konuya müdahale etmekle de sorumludur. Ayrıca kendisi üzerinde yer alan yöneticiye de durumu raporlar. Bu tip projelerde genelde yazılım mimarları ya da bir mimar yoksa kıdemli mühendisler ekipte takım lideri konumunda, ekip yöneticisine daha yakın pozisyonda çalışırlar. Her türlü işin doğru gittiği, projelerin başarıyla bitirildiği hikayeler kadar, sektörde ve özellikle Türkiye’ de IT departmanları ve entegratör firmalar, iyi başlattığı ama bitiremediği projeleriyle meşhurdur. İşte burada devreye Enterprise Architecture giriyor. İş somut olarak gözlemlendiğinde, bir projenin başarıyla bitirilememesinin sebeplerinin başında teknik eksiklikler, yetki devri problemleri, departmanlar arası çatışmalar, maliyet analizlerinde hatalar, veri güvenliğinde hassasiyetin korunmaması vb faktörler geliyor.
Kurumsal mimari; departman yapısı gereği, yukarıda saydığım etmenlerin hemen hemen her biri için ayrı alt birimler kurduğundan ve proje ya da iş paketinden bağımsız hareket ettiğinden; teknik olarak bir yazılım mühendisinden veya bir sistem yöneticisinden ayrılıyor. Bir üst katmanda bu konulara önceden çözümler sunarak, stratejiler ve dinamik çözümler getirerek, bir bakıma sistem ve yazılım geliştirme departmanlarının yapması gereken işi önceden belirliyor. Bu kurallar bütününü tüm departmanlara bir Enterprise Environmental Factors mantığıyla aşıladığı için, departmanlar ve aynı yetkilere sahip yöneticiler arasındaki çatışmaların da önüne geçebiliyor.
Kısa örneklerle anlatmaya çalışalım. IT departmanımızda; veritabanı yöneticileri, sistem mühendisleri, yazılım mühendisleri, iş analistleri, veri madenciliği yapan çalışanlarımız olsun. Strong matrix şemasına göre organizasyon şeması aşağıdakine benzer bir yapıda olacaktır :
Yukarıdaki ekibe gelen her iş ya da proje, her seferinde tekrar tekrar toplantılarla uzun uzun tartışılır. Her seferinde mutlaka fikir ayrılıkları çıkar. Hem yönetici için; ekibin tamamını mutlu edememek gibi bir durum doğar, hem de alt kadroda çalışanlar, kendilerine verilen yetkilerden ya da work packagelerdan memnun kalmayabilirler. Bu da uzun vadede ekibe ve nihayetinde kuruma zarar verecektir. Bu işin organizasyonel boyutuydu. Teknik olarak ise; örneğin ekipteki dba, veri tabanındaki bir tasarım değişikliğini nasıl yapacağı konusunda fikir sahibi olmak için önce ekip arkadaşı ile sonra bir üst yöneticisi ile daha sonra da IT Manager olarak görünen birim ile iletişime geçmek durumunda kalacaktır. Bütün bu işler, manual olarak yürürken harcanan zaman, para, performans kaybı şirketlere zarar veren en büyük etkendir. Peki, kurumsal mimari olsaydı bu işin önüne nasıl geçilirdi?
Yukarıdaki şemada belirtildiği ( yalnızca database administration örnek verilmiştir, hepsi için aynıdır ) gibi; Enterprise Architecture departmanında mimarlar tarafından önceden yazılmış kurallar, IT departmanında ilgili birimlere iletilir ve bu süreç şirket çalıştığı sürece devam eder. Prosedür yazma, strateji kurma, hedef belirleme, hangi proje yönetim yaklaşımının kullanılacağının belirlenmesi ve hangi teknolojilerin nasıl kullanılacağı konusunun asıl belirlendiği bölüm, kurumsal mimari departmanıdır. Şirketiniz bu şekilde çalışmaya başladığı andan itibaren, IT departmanında işlerin rayına oturduğunu gözlemleyebilirsiniz. Çünkü artık, departman yöneticisi ve altında çalışan kadrolar, kendi alanında uzman kurumsal mimarların oluşturduğu altyapılarda hazır sistemler üzerinde sistem entegre edebilecekler, veritabanı tasarlayabilecekler ya da kod yazabileceklerdir. Böylelikle hem yönetici teknik olarak olarak hafifleyecek, hem ekip içerisindeki fikir ayrılıkları ciddi derecede azalacak, ek talepler direkt olarak Enterprise Arcihtecture departmanına iletilecek, hem de uzun vadede şirket kendiliğin bir IT standardizasyonuna kavuşmuş olacaktır.
Bu konuda güzel bir de sunum önereyim : Enterprise Architecture Roles And Competencies V9
Son olarak belirtmek isterim ki; bir şirketin IT ekibi, kendi alanında en iyi kişilerden oluşabilir. Tüm alt kadrolar ve proje yöneticileri kendilerine verilen görevleri en iyi şekilde yerine getirebilirler. Fakat, bütün bu saydıklarımız, bir sistem varsa mümkündür. Kurumsal mimarinin temel görevlerinden biri, bir kurumun uzun vadeli hedeflerini anlayarak analiz ettikten sonra, IT departmanlarında bunu bir sistematiğe bağlayıp sürekli olarak işletmek ve kendisi dışındaki departmanların düzgün çalışmasına yardımcı olmaktır.