Türkiye’de Kurumsal Mimari Gelişimi Konusunda Sıkıntılar Ne?

•      Biz kültürel özellik olarak tasarım yapmayı, planlama yapmayı sevmeyen bir milletiz. Tasarım yaptığımız zaman sanki projeler duruyor gibi geliyor insanlara. Hemen iş üretelim hemen çalıştıralım mantığı var.

•    İş tarafı da teknolojiyi üzerinde çalışılması gereken bir şey gibi görmüyor. “Yapsana ne var yapamıyor musun, çabuk yapanlar var“ mantığında. Bilişim Teknolojileri içinde tasarıma planlamaya önem veren insanlar olsa da işleriyle ilgili performans kaygısı yaşadıkları için ellerinden geldiği kadar işleri  çabuk bitirmeye bakıyorlar.

•       Kurumsal Mimari’de iş tarafını dahil etmek çok önemli. Bu yüzden yabancı şirketlerin bir kısmında Kurumsal Mimari Departmanı’nın iş tarafında (BT dışında) yapılandığını görebilirsiniz– hatta bazı şirketlerde KM biriminin adı İş Dönüşümü ve KM birimi. Ancak maalesef iş birimlerini Kurumsal Mimari ile ilgili çalışmalara dahil etmek çok kolay değil. En basitinden “Bana iş stratejilerini ver, ben de BT stratejilerini oluşturacağım” diyoruz. İş stratejileri çoğu yerde yapısal bir şekilde oluşturulmuyor,  çok üst seviye  bir takım sunumlarda yer alıyor.  Bunları alıp BT stratejisi yapıp mimariyi şekillendirmek mümkün değil. İkinci konu ise iş süreçlerini ve BT nin bu süreçlerini nasıl karşıladığının analizi için modelleme yapmak… İş süreçlerindeki her değişiklikten maalesef BT nin haberi  olmuyor. Bu yüzden yapılan modellerin güncelliği konusunda ciddi şüpheler oluşuyor. Özetle Kurumsal Mimari’ de her yol iş mimarisine çıkıyor. Bu yüzden yola çıkarken mutlaka iş birimlerinden ciddi destek alıyor olmak lazım.

•     Kurumsal mimari konusundaki know-how çoğu zaman bu konudaki araçların satışçılarından geliyor. Bunlar araç satma heyecanı içinde Kurumsal Mimari konusunda sırf üst düzey yöneticileri etkilemek için çok iddialı hedefler öne sürüyorlar. Maliyet analizi ve etki analizi bu çerçevede gösterebileceğim şeyler… Önceden belirttiğim gibi asıl konular bunlar değil, asıl konu BT ve iş tarafının hizalanması (alignment), etkinlik, verimlilik ve standardizasyon.

•     Kurumsal mimarinin katma değeri ölçülebilir değil. Yapmadığın zaman kaybettiğin şeyi yaptığın zaman kazandığın şeyi tam olarak ifade edemiyorsun. Hem üst düzey yöneticilere anlatmak hem de bu konuda çalışan personele faydayı ispatlama zor oluyor. Bu yüzden çalışacak insan bile bulmak sıkıntılı oluyor. O yüzden hep üstüne basa basa söylüyorum. Her organizasyon Kurumsal Mimari’nin hangi fonksiyonu gerçekleştirerek hangi yaraya iyi geleceğini yani “katma değeri” oturup konuşmalı ve üstünde mutabık olunuyorsa “hadi başlayalım” demelidir.  Ama aktif ama pasif kurum içinde direnç kaçınılmazdır. Kurum kültürü, içinde bulunulan koşullar bu işleve hazır değilse Kurumsal Mimari yapılmayabilir, aksi halde bu fonksiyonu yerine getirmeye çalışanların ciddi şekilde demotive olduklarını gözlemleyebilirsiniz.

•     Bu alanda çalışırken yaşanan en önemli sorunlardan biri de şu: tasarlıyorsunuz ama implementasyonu siz yapmıyorsunuz. Diyelim yazılımdaki servisleri tasarladınız, ya da altyapı platformları tasarladınız. Peki bunlar bu şekilde yapıldı mı, yapılabildi mi ? Sürekli bunu kontrol ediyor olmanız lazım. İdeali şu… Eğer implementasyon yapılırken  birtakım tasarım hataları ya da değişiklikler tespit edildiyse mimara gelinmesi ve tasarımı hatta standartı değiştirmenizin talep edilmesi, tasarım hataları yoksa da belirtildiği şekilde implemente edilmesi. Yani implementasyon yapanlardan geri bildirim almanız lazım. İletişim yolları karşılıklı sürekli açık olmalı. Sürekli kontrol yapamazsınız. İkinci bir konu : Implementasyonun içinde olmadığınız için çok detaylı bilgiye sahip değilsiniz ama o domaindeki önemli kararları da vermek zorundasınız. Bu da bir conflict(çatışma) yaratıyor. Bu yüzden detaylı bilgiye sahip kişiden bilgi alıp ona itibar etmek zorunda olmak gibi bir durum ortaya çıkıyor. Hem içindesin bu çemberin hem de dışında yer alacaksın?

Kim mimar olmalı, sahip olunması gereken özellikler var mı, varsa neler?

Önceki yazılarımda bahsettiğim gibi çok farklı mimari fonksiyon  var. Her mimari fonksiyon için değişik background lara ihtiyaç var, inanın çoğu “teknik” olmak zorunda değil.  Bir takım “soft skills” diyebileceğimiz şeyler var ki bunlar tüm mimarlarda olmalı:

•Araştırma geliştirme  yapmayı sevmek, meraklı olmak: Teknolojideki hatta işteki(bankacılık, telekom vs.)  değişikleri takip edip Bilişim Teknolojileri’ ne yön verebilecek stratejileri belirlemek. Bunu gelecek mimarileri oluşturmak için kullanacak.

•Dokümantasyon yapmayı sevmek: Kendi sahasındaki standart, prosedür ve politika dokümanlarını oluşturmak. Geliştirme dünyasındaki gibi “önce pratik sonra dokümantasyon” dememek

•İyi bir analist olmak:   Süreçleri, yetenekleri, ürünleri analiz edebilmek, bütüncül ve kurumsal bakış açısına sahip olmak. Doğru yerde doğru soruları sorabilmek…

•Kendinden güdümlü olma :  “Self motivated”. Mimar kendine bir iş verildiği zaman mutlaka yapan, kendi kendini yöneten bir roldür.  Yani mimarın yöneticisinin senin şu işin vardı, yapıyor musun diye task takibi yapmasına gerek yoktur.  Mimar zaten yöneticisine sorun varsa gelir, gelmiyorsa da zaten o proje sorunsuz yürüyordur.  Bu motivasyon kişide yoksa zaten mimar olmamalıdır.

•Hem sözlü hem yazılı iletişim yeteneğinin yüksek olması :  Bu konu en önemlisi. Mimarların iki görevi vardır. Biri standartları ve politikaları oluşturmak ve ilgili ekiplere iletmek(rehberlik), ikincisi de uymadıkları zaman onlara dur demek(polislik)- bir nevi yasama ve yürütme. Verilen işi yapayım, suya sabuna dokunmayayım, kimseyle de kötü olmayım, görev tanımım belli olsun, sunuma falan beni bulaştırmayın diyorsanız mimarlık size göre değil. Mimarlar projelerde sorunlar çıktığı zaman inisiyatif alıp çözüm üretebilmeli,  standartlara ve politikalara referans vererek kendi önerdikleri çözümün rasyonel dayanağını belirtmeli ve ilk önce tarafları ikna etmeye çalışmalıdır. Eğer ikna yolları kapalı ise kurumun süreçlerinde verilen yetkiye göre eskalasyon mekanizmalarını işletmelidirler. Burada “saygı” çok önemlidir. Mimarların da proje ekibinin de birbirine “saygı” çerçevesinde hareket etmesi gerekir.

•Sağlam durma : “Assertive?” Aslında daha da açarsak mimarlar sert duruşlu mu olmalı? Bence bir şeyi “sert” söylemek “haklı” olmak anlamına gelmiyor. Sizin sağlam durmanızı sağlayan şey önerdiğiniz çözümün ne kadar standarta politikaya uygun olduğu - hadi her yaşanan sorun için yazılı bir kuralınız olmayabilir – ne kadar etkin,  verimli özetle iyi bir çözüm olduğudur. Çok “sert” olmanın da iletişim yollarının kapamak gibi bir dezavantajı var. İletişimi sürdürülebilir bir seviyede tutmak gerekir. “Polislik” görevini teftiş gibi algılamamak lazım. Mimarlar bulgu bulup geri çekilmezler, nasıl yapılacağı konusunda öneri de getirirler.  Burada şunu da belirtmeden geçemeyeceğim. Standartlar politikalar oluşturulurken mimari ekipler “Biz böyle uygun gördük” dememeli, bu standardı uygulayacak ekiplerle beraber çalışma grupları oluşturmalı ve onlara bu kuralları sahiplendirmelidir. Burada bir önceki maddedeki iletişim yeteneği öne çıkıyor. Bilişim Teknolojileri sektörü yüksek yetkinlikte, çalışkan, idealist ve yüksek egolu insanlarla doludur.  Kimseyi sadece “sopa göstererek” düzene sokamazsınız. Herkes kendi fikirlerinin dikkate alınmasını, dikkate alınmıyorsa nedenini ve en nihayetinde ikna edilmeyi bekler.

Mimar olmanın kolay olmadığını, görev tanımının geniş olduğunu ve sorumluluğunun çok olduğunu söyleyebilirim. Bu durum zaman zaman “Acaba ne kadar iyi yapıyorum?” gibi kişisel sorgulamalara da yol açmıyor değil. Başka ekiplerden  mimari ekiplere geçenler “betona çarpmış” gibi hissettiklerini sıklıkla söylerler. Ama benim gözlemim zamanla bütüncül bakış açısı ve iletişim yetenekleri geliştirilebiliyor, sabırlı olmak lazım. Sonradan gelişmeyen tek şey ne biliyor musunuz, merak .….

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.

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.