IT dünyasının içinde olanlara bile Kurumsal Mimarı (KM) kavramını anlatmak, onları bu işin gerekliliğine ikna etmek zorken (hatta gerekliliğinden çok yapılabilirliğine), bu işi iş birimlerine anlatmak ve onları ikna etmek apayrı bir ustalık gerektirir. İşte bu noktada kullanabileceğiniz silahlardan biri de ‘Kurumsal Mimari Araç’ larıdır.
‘Araç’ konusuna sadece satış aşamasında kullanılabilecek bir silah olarak bakmak işi baya hafife almak demek aslında. Hatta işi ‘KM aracı satmak’ olarak görmek de söz konusu, ki bu da odağı KM yönetiminden alıp araç yönetimine odaklar ve KM programını başarısızlığa kadar sürükleyip kurumları bu işten vazgeçirebilir.
Araç konusunu daha da başa sararsak soruyu ‘Araç gerekli mi?’ diye sormak lazım. Araç bir zorunluluk değil. Kurduğunuz/Kullandığınız framework e göre araç ihtiyacı olmayabilir de. Yönettiğiniz artifactler veya deliverable lar, mimari modelleriniz, temel ofis uygulamaları veya açık kaynak modelleme araçlarında yönetilebilir pekâlâ. Fakat KM sadece dokümantasyondan ibaret değil – olmamalı. Bu belgelerin varlığı bir ‘iş’ çıkardığınızı gösterse de asıl sorgulanacak şey çıkardığınız işin katma değer üretip üretmediği olacaktır. Peki, aracın katma değer üretmenize katkı sağlaması için ne ‘yapabiliyor olması’ lazım?
- Üretilen çıktıların, modellerin, envanterlerin (portföylerin) tek bir ortamda yönetilmesi ve farklı katmanlarda ilişkilendirilmesi à Etki analizi sağlar.
- As-is ve To-be mimarilerinin (idealde) tek bir tık ile karşılaştırılabilmesi à To-be mimarilere gitmek için yapılması gereken işlerin (projeler, programlar, çalışmalar, vb.) belirlenmesini sağlar.
- İş/Teknoloji stratejileri, talepler ve projeler ile mimari ürünlerin ilişkilendirilmesi à İş ile IT arasındaki hizalanmanın izlenebilir olmasını sağlar.
- Kurumsal mimari prensip ve standartların tutulacağı bir bilgi bankası à Bu bilgilerin kurum içinde bilinir, erişilebilir olmasını sağlar.
- Kurumsal mimari uyumluluk değerlendirme için bir kayıt havuzu à Kurumda KM uyumluluğunun denetlenmesini kolaylaştırır.
Tabi bunları söylemesi kolay. Araç kullanımından, ya da şöyle diyeyim, tüm mimarinin tek bir araçta yönetilmesi konusundan neden uzak duruluyor? Birkaç farklı sebebi var: Bunlardan birincisi, araç kullanılırsa ortaya çıkacak efor – hem satın alma öncesi hem de sonrası ortaya çıkacak efor. İkincisi işin maliyeti. Bu araçların bir kısmı gerçekten maliyetli. Ayrıca iş satın alma maliyeti ile de bitmiyor. Aracın danışmanlığını da almak zorundasınız. Bakım maliyeti ayrı bir kalem.
- Aday araç, kullandığım frameworkün kapsadığı mimari katmanların hangilerini destekliyor?
Örneğin altyapı mimarisini ve bağlı modellemeleri, nesneleri desteklemeyen bir aracı tercih etmeyebilirim.
- Aday araç, ürettiğim artifact ve deliverable larımı, mimari öğelerimle ilişkilendirmeme ve araç üzerinde takip etmeme izin veriyor mu?
- Aday araç, entegrasyon ihtiyacı duyduğum noktalarda bana nasıl imkanlar sağlıyor? Örneğin uygulama portföyümü proje yönetim aracımla paylaşmak isteyebilirim. Veya veri mimarisi katmanındaki öğelerimi fiziksel veri modelleme aracıma göndermek isteyebilirim.
- Aday araç, hangi mimari standartları destekliyor? Kurumda Archimate veya TOGAF ın metamodelini kullanmak isteyebilirim. Aday araç bunları için hazır bileşen seti ile mi geliyor yoksa özelleştirme gerekir mi?
- Aday araç, mevcut bileşenlerin özelliklerini ihtiyacıma göre genişletme (extendable) imkanı sunuyor mu?
- Aday aracın raporlama (görsel sunum veya belge üretme) yetenekleri nelerdir?
- Aday araç, çok kullanıcılı bir çalışma ortamına izin veriyor mu?
- Aday araç, KM modellemesi dışında bir modelleme imkanı sunuyor mu? Örneğin iş süreçlerimi de BPMN ile modellemek ve süreç detaylarımı iş mimarisi ile ilişkilendirmek isteyebilirim.
Aracı nerede (hangi süreçlerde kimler tarafından) kullanacağınızı netleştirdikten sonra bu soruları daha da artırmak mümkün. İşin içine versiyonlama, yetkilendirme gibi daha teknik detaylar da girecektir.
Gartner 2004’ten beri (muhtemelen daha biz Kurumsal Mimari’nin ne olduğunu bile bilmiyorken ve Kurumsal Mimari’yi diğer mimari disiplinler ile karıştırırken) piyasadaki KM araçları ile ilgili Magic Quadrant yayınlıyor – konuya aşina olmayanlar için, Magic Quadrant piyasada belirli bir Pazar payına ve olgunluğa sahip ürünlerin değerlendirilip karşılaştırıldığı bir analiz. Gartner’ın bu yaklaşımı aslında hem araç konusunun hem de KM yönetiminin önemini bir nebze işaret ediyor diyebiliriz.
Gartner’ın magic quadrant’ında yer alan araçların bir kısmının Türkiye’de temsilcilikleri var. Fakat hangisi piyasada ne kadar yaygın derseniz biraz kısır bir tablo çıkıyor ortaya. Bu sebeple tercih edeceğiniz aracın (ofis uygulamalarından vazgeçebilirseniz) Türkiye’deki mevcut danışmanlık deneyimi de önem kazanacak. Ayrıca alınacak danışmanlığın KM disiplininize ne kadar katkı sağlayabileceği de ayrı bir soru işareti. Ek olarak Türkiye’de yer alan bazı yabancı menşeli firmalar yurtdışı merkezlerinin kendilerine zorunlu tuttuğu KM araçlarını da kullanıyorlar. Tabi zorunluluk olduğu için bu araçlar ne verimlilikte kullanılıyor bilemiyorum.
Bu arada Gartner’ın çalışmasında yer alan araçların hepsinin güçlü yanları ayrı. Kimisi daha stratejik açıdan yaklaşırken kimisi daha standart temelli gidiyor. Araştırma yaparken deneme sürüşünü yaptığım araçlar BiZZDesign Architect Ve Avolution Abacus oldu. Bu araçlarla ilgili yorumlarımı ayrı bir yazıda toparlamayı düşünüyorum.
Peki, sonuç ne: Araç kullanımı gerekli mi? Bence kesinlikle gerekli. Tek bir şartla; önce KM disiplininizi ve frameworkünüzü tanımlamalı, geliştirmeli ve yerleştirmelisiniz. Hangi katmanda, hangi çıktılarla, hangi süreçlerde, hangi detayda KM yapacaksınız? Araç tek başına hiçbir mimari sorunuza cevap vermeyecektir. İkinci sorumuz da belli; hangi aracı kullanmalı? Bu sorunun tek bir cevabı yok. Piyasada yetkinlikleri birbirinden farklı çok araç var. Siz KM olarak ne yapacağınıza karar verdikten sonra araç seçmek kolaylaşacaktır.
Not: Artifact ve deliverable TOGAF terimleri. Kısaca açıklamak gerekirse
- Artifact mimarimizi belirli bir bakışa açısından tanımlayan mimari çalışmadır. Diagramlar, katalog ve matrisler şeklinde hazırlanabilir.
- Deliverable bir proje sürecinde hazırlanan, gözden geçirilen ve tüm paydaşlar tarafından mutabık kalınan çıktıdır. Deliverable lar bir veya birden fazla artifact içerebilir.
Yazının orijinali http://kurumsalmimari.blogspot.com.tr/2015/08/kurumsal-mimari-araclar.html adresinde yayınlanmıştır.