SOA ve Sınırsız Bilgi Akışı (Boundaryless Information Flow)

SOA ve Sınırsız Bilgi Akışı (Boundaryless Information Flow)

Open Group un en önemli vizyonlarından biri Sınırsız Bilgi Akışı dır. TOGAF ta da Sınırsız Bilgi Akışı nın izlerini bulmak mümkündür. Buna göre departmanlar, organizasyon seviyeleri, kurumlar ve milletler arasındaki sınırlar bilgi akışı açısından geçirgen olmalıdır. Bu prensip ilk defa 1980 yılında GE den Jack Welch gibi öncüler tarafından ortaya atılmıştır. Open Group bu prensipi ele alarak, Interoperable Enterprise Business Scenario  adı altında tanımlamıştır.

Geleneksel IT, iş süreçlerinin birbirinden bağımsız bir şekilde çalıştığı sistemlerden (bilgi silolarından) oluşur. Her sistemin kendi arayüzleri ve bilgi formatları vardır.

SOA ile bilgi silosu halindeki uygulamalar/sistemler, birbirleriyle etkileşim halinde olan servislere dönüştürülür. Servislerin etkileşimi tipik olarak Enterprise Servis Bus üzerinden, ya da web üzerinden dış servislerle implemente edilebilir. Bu mimari Sınırsız Bilgi Akışı’nın gerçekleşmesine imkan verir.

 

Sınırsız Bilgi Akışı’nın gerçekleştirilmesini sağladığı için SOA Open Group için çok önemli bir yere sahiptir.

SOA nın Özellikleri ve Faydaları

SOA nın kurumsal çeviklik konusunda faydasını üç başlıkta toplamak mümkündür:

·         Servislerin  birleştirilmesi (service composition)

·         Model yönelimli geliştirme (model driven development)

·         Servis sanallaştırma (service virtualization)

 

Aşağıda SOA nın özellikleri ve faydalarından detaylı bir şekilde bahsedilmiştir. Organizasyonun ihtiyaçları doğrultusunda uygun olan SOA özelliği seçilebilir.

Özellik	Fayda	Destekleyici Altyapı
Servis	Ø  Gelişmiş bilgi akışı Ø  İçerideki işlevselliğin dışarıya sunulabilmesi Ø  Organizasyonel esneklik
Servis tekrar kullanımı	Ø  Yönetim ve yazılım geliştirme maliyetlerinin düşürülmesi	Servis havuzu (repository)
Mesajlaşma	Ø  Konfigürasyon esnekliği	Mesajlaşma ile ilgili program
Mesajlaşmanın izlenmesi	Ø  İş zekası Ø  Performans ölçümü Ø  Güvenlik ataklarının tespit edilmesi	Aktivite izleme(BAM diye de geçiyor)
Mesajlaşmanın kontrol edilmesi	Ø  Yönetim politikalarının uygulanması Ø  Güvenlik politikalarının uygulanması	PDP ler ve PEP ler
Mesajların dönüştürülmesi	Ø  Veri çevrimi	Veri çeviriciler
Mesaj güvenliği	Ø  Verinin bütünlüğü ve güvenilirliği	Şifreleme motoru
Karmaşık olay işleme(CEP)	Ø  Yazılım  yapısının basitleştirilmesi Ø  Birbirinden farklı dış ortamlara kolay uyum sağlayabilme Ø  Gelişmiş yönetim ve güvenlik	Olay motoru
Servislerin birleştirilmesi	Ø  Yeni fonksiyon kombinasyonlarının hızlı bir şekilde geliştirilebilmesi	Birleştirme motoru (Composition engine)
Servislerin keşfi	Ø  Performans, fonksiyonalite ve maliyetin optimize edilmesi Ø  Sistem yükseltmelerinin daha kolay yapılabilmesi	Servis kütüğü (registry)
Varlıkların paketlenmesi	Ø  Mevcut varlıkların entegre edilebilmesi
Sanallaştırma	Ø  Güvenilirliğin artması Ø  Değişik seviyelerde talep edilen servis operasyonlarının ölçeklenebilmesi
Model yönelimli geliştirme	Yeni fonksiyonların hızlı bir şekilde geliştirilebilmesi	Model yönelimli geliştirme ortamı

 

 

REFERANSLAR:

http://www.opengroup.org/soa/source-book/soa/soa_ea.htm#X_SOA_and_Enterprise

http://www.opengroup.org/soa/source-book/soa/soa_bif.htm#fig4

http://www.opengroup.org/soa/source-book/soa/soa_features.htm

 

TOGAF ve SOA

TOGAF ve SOA

Kurumsal mimarlar TOGAF ı kullanarak kurumun tüm yapısına üst seviye olarak bakarlar. SOA ise daha çok bu yapının nasıl kurulacağına dair özel bir yapı tekniğidir. Aynı inşaatta olduğu gibi yapı tekniğinin toplam yapının oluşmasında büyük bir etkisi vardır(Örneğin çelik çerçeve tekniği gökdelenlerin yapılabilmesine imkan vermiştir). SOA,  IT mimarisinde benzer bir etki yaratabilir. Bu anlamda SOA belki IT sistemlerin daha fazla büyümesini sağlamaz ama en azından beraber çalışması (interoperability) ve yönetilebilirlik konularında ciddi fayda sağlayabilir.

SOA daki belirtilen servisler aslında sanıldığının aksine teknik servisler değil, iş servisleridir. İş servisleri,   gerçek hayattaki iş süreçlerini oluşturan iş aktiviteleri baz alınarak belirlenir. Bu şekilde gerçek hayatla yazılımın birbiri ile uyumlu olması sağlanır.

Open Group, SOA ile uygulamaları geliştirmeye başlamadan önce SOA Referans Mimarisi nin oluşturulmasını tavsiye etmektedir. Bu referans mimari:

• SOA da yer alan yapıtaşlarının (building block) tanımlandığı ve konumlandırıldığı referans mimari
• Örneklerle birlikte dokuz katmanlı referans mimarinin üst seviye perspektif mimarisi
• SOA nın özelliklerinin nasıl gerçekleştirileceğini gösteren detaylı modellerin yer aldığı referans mimari
• Altyapı ürünlerinin SOA yı desteklemek için hangi yapıtaşlarını (building block)  kullanacağını tanımlayan altyapı referans mimarisi
• SOA Endüstri standartlarından oluşur. 

Bu referans mimarilerin çıkarılması aslında Kurumsal Mimari nin ta kendisidir.  Bu referans modellerde hangi yapıtaşının hangi katmanda yer alacağı, hangi fonksiyonu gerçekleştireceği belirlenmektedir. Referans mimarilerde mimari (architecture) yapıtaşları belirlendikten sonra bunlar çözüm (solution) mimarisine indirgenmekte yani ete kemiğe dönüşmektedir.  Bu aşamadan sonra çözümler ya kurum içinde mimaride belirlenen fonksiyon kümesiyle geliştirilmekte ya da hazır paket olarak satın alınmaktadır.

Yukarıdaki bahsedilen referans mimarilerden sadece ikisi gösterilmiştir.

Burada Bilişim Teknolojileri’nde gördüğüm SOA konusunda gördüğüm bir zayıflıktan bahsetmek isterim. Genellikle yeni bir kurumsal uygulama geliştirilirken veya teknoloji ve mimari seçimler yapılırken bir takım danışmanlıklar alınıyor, firmalarla görüşmeler yapılıyor. Bu danışman firmalar doğal olarak “SOA uygulayın”, “EDA uygulayın”, “kural motoru alın”, “süreç motoru alın”,  “CEP uygulaması alın” gibi bir takım tavsiyeler veriyorlar. Bahsedilen uygulamalar da alınıyor. Ancak bunlar alındıktan sonra kurum içinde bunların neden alındığı, nasıl konumlandırılacağı sadece yazılım geliştirmeciler tarafından değil, mimari ekipler tarafından bile bilinmiyor, iletişimi iyi yapılmıyor. Mimari ekiplerin burada sağlayabilecekleri katkı aslında büyük. Mimari ekipler ilk önce SOA nın ana felsefesine hakim olmalı,  SOA yla beraber gelen kural motoru, süreç motoru, olay motoru gibi yatay uygulamaları (SOA özelliklerini) iyi bilmeli ve gerçek hayattaki projelerde yazılım geliştirme ekiplerine liderlik yapıp bunların uygun olan yerlerde kullanılmasını ve verimliliğin artırılmasını sağlamalıdır. Eğer böyle yapmaz isek SOA nın çok katmanlı yapısından, çevikliğinden faydalanmamız, yaptığımız yatırımların karşılığını almamız mümkün değil.

TOGAF taki Content Model de  SOA varlıkları ile eşleşen yerler aşağıda kırmızı ile çizilerek gösterilmiştir:

Bu eşleşmeye göre TOGAF ın iş mimarisinin belirlendiği B fazı, uygulama ve veri mimarisinin belirlendiği C fazı ve altyapı mimarisinin belirlendiği D fazında oluşturulmasını tavsiye edilen artifactler (yani mimari ürünler, çıktılar, şekiller, dokümanlar gibi düşünebilirsiniz bunları) aşağıdaki gibidir:

Faz	Artifact
Faz B	İş servisleri etkileşim diyagramı
Faz B	İş süreçleri diyagramı
Faz B	İş Kelime Kataloğu
Faz B	İş servisleri Kataloğu
Faz B	İş servisleri /lokasyon kataloğu
Faz B	Olay /süreç kataloğu
Faz B	Kontrat/Servis Kalitesi kataloğu
Faz B	İş servisleri Etkileşim kataloğu
Faz B	İş servisi/Bilgi Matrisi(CRUD)
Faz B	Bilgi Bileşen Modeli
Faz C	Servis Etkileşim Diyagramı
Faz C	İş süreçleri/Servis Matrisi
Faz C	Servis Kontrat Kataloğu
Faz C	Servis/Uygulama Kataloğu
Faz C	Servis/Veri Varlığı Matrisi
Faz C	Mantıksal Bileşen Matrisi
Faz C	Mantıksal SOA Çözüm Diyagramı
Faz C	Servis Dağıtım Matrisi
Faz D	Mantıksal Teknoloji Mimari Diyagramı
Faz D	Mantıksal Uygulama/Teknoloji Matrisi

Yukarıda belirtilen artifactlerin hepsini SOA da uygulama ya da altyapı geliştirirken üretmek mümkün olmayacaktır. Ancak kurum kendine göre metodolojiyi özelleştirebilir. Belirli durumlarda belirli artifactlerin üretilmesi ya da üretilmemesi kararını verebilir. Bazı artifactlerin mimari ekip tarafından diğerlerinin yazılım geliştirmeciler tarafından üretilmesi sağlanabilir. Ama şunu asla karıştırmamak gerekir: yukarıdaki artifactler yazılım geliştirmeciler tarafından yapılsa dahi hala mimari çalışmanın bir parçasıdır (mimari ekibi her kurumda fiziksel olarak vücut bulmayabilir). Burada üretilen artifact lerin kalıcı olarak bir repository de (havuzda) saklanması için bir araç kullanabilir.  Bunların hepsi ekstra iş yükü ve yatırım olarak gözükse bile uzun vadede verimliliğin sağlanması konusunda ciddi fayda sağlayacaktır. Günümüzde bankacılık uygulamaların ömrünün en fazla on yıl olduğu söylenmekte. Belki de bu şekilde mimariyi sürekli olarak gözden geçiren bir süreçle/çalışmayla yazılımların ömrünü uzatmak da mümkün olabilecektir.

Özet olarak Kurumsal mimari SOA için aşağıdaki faydaları sağlar:

• Üst düzey stratejiler ile çıktılar arasında tutarlılık sağlar.
• İşle ilgili problemlere iş, veri, uygulama, teknoloji gibi değişik perspektiflerden yaklaşmayı sağlar.
• Gelecek duruma ulaşmak için yol haritasının netleşmesini sağlar.
• IT varlıkları ile desteklediği iş arasında bağlantılar kurarak izlenebilirliği artırır.
• Risk/değer analizi, portföy yönetimi, etki analizi süreçlerini destekler.
• Prensiplerin, kısıtların, standartların, çerçevenin belirlenmesini sağlar.
• Karar verici otoriteleri destekleyici yönetimi çerçeveleri ve süreçler sağlar.

Kurumsal mimari SOA daki analiz imkanlarını aşağıdaki fonksiyonları gerçekleştirerek destekler:

• SOA çözümlerinin iş yeteneklerini nasıl en verimli şekilde tasarlanacağını gösterir.
• Hangi servislerin geliştirilmesi hangi servislerin yeniden kullanılması gerektiğini gösterir
• Hangi servislerin tasarlanması gerektiğini gösterir

Kurumsal mimari olmaması aşağıdaki olumsuz durumlara neden olur:

• Çevikliğin azalması
• SOA servislerinin belirlenmesi ve yönetilmesinde zorluk
• Servisleri gelişigüzel sayısının artması
• Giderek artan yönetişim sorunları
• SOA servislerinin beraber çalışmasının kısıtlı hale gelmesi
• SOA nın çoklu bilgi siloları haline dönüşmesi
• SOA geliştirmelerinde zorluk
• İş servisleri ve uygulama/platform/yazılımlar arasındaki eşleşmenin ve takibinin zorlaşması

REFERANSLAR:

Chapter 22 Using TOGAF to Define & Govern SOA, TOGAF Version 9.1 

TOGAF

Kurumsal mimari konusunda aslında tek framework TOGAF değil. Başka frameworkler de var. Bunlarla ilgili aşağıdaki blog da ilginç bir yazı buldum:

http://blog.goodelearning.com/togaf/architecture-frameworks-passive-active-theoretical-useful/

Başka frameworkler olsa da TOGAF, The Opengroup’ın katkılarıyla yaygınlık konusunda ciddi bir şekilde öne geçti. Eğitim ve sertifikasyon ile ilgili konular da tahmin edebileceğiniz gibi gayet düzgün bir şekilde yürütülüyor. Peki TOGAF ne anlatıyor? Başından sonuna kadar Kurumsal Mimari’yi oluşturmak için gerekli olan süreçleri, araçları, teknikleri, yetenekleri bize tarif ediyor, genel bir çerçeve çiziyor.

Ancak TOGAF’a ait, The Opengroup’ ta yayınlanmış en temel doküman - TOGAF Version 9.1 -  654 sayfa, okunabilecek gibi değil. Ben başından sonuna kadar okuyanını da görmedim. Hadi sayfa sayısını geçtim, zaten mimari soyut bir kavram, soyut olan bir şeyin nasıl yapılacağını da çok genel kavramlar üzerinden, bir de İngilizce anlatmış. Hakikaten anlaması zor. TOGAF’ın 5 günlük sertifikasyona yönelik eğitimlerinden sonra bile, ancak TOGAF’ın ne olduğunu anlayabilirsiniz. Bunu uyarlamak ise bence deneyim işi. Eğer TOGAF ı kendiniz uyarlamaya and içtiyseniz ciddi zaman ve çaba harcamalısınız ya da vaktiniz yoksa bu konuda danışmanlık desteği almalısınız.

Peki TOGAF kısaca ne?

TOGAF  dört tane Kurumsal Mimari alanını kapsar:

• İş mimarisi
• Veri Mimarisi
• Uygulama mimarisi
• Teknoloji Mimarisi

TOGAF 9.1, bu 4 alanı kapsayacak şekilde 7 bölüm içerir:

Bölüm 1 : Tanıtım

Kurumsal mimari ile ilgili önemli kavramların üst seviye anlatıldığı bölümdür.

Bölüm 2 : ADM (Architecture Development Method)

TOGAF ın en önemli yeri burası aslında. Bu bölümde Kurumsal Mimarinin adım adım nasıl geliştirileceği yer alır.

Bölüm 3 : ADM Rehberleri ve Teknikleri  (ADM Guidelines and Techniques)

TOGAF ve TOGAF ADM i uygulamak için kullanılabilecek teknikler ve rehberler burada detaylı bir şekilde anlatılır.

Bölüm 4: İçerik Çerçevesi (Architecture Content Framework)

TOGAF içerik çerçevesi, tekrar kullanılabilecek mimari yapıtaşlarını (building blocklar), mimari artifactler için yapılmış metamodelleri ve mimari çıktıları içerir.

Bölüm 5: Enterprise Continuum& Araçlar

Burada mimari aktivitelerinin çıktılarının saklanması ve sınıflandırılması için kullanılabilecek birtakım taksonomilerden ve araçlardan bahsedilir.

 Bölüm 6: TOGAF Referans Modelleri

Bu bölümde TRM (Technical Reference Model) ve III-RM (Integrated Information  Reference Models) gibi referans modellerden bahsedilir.

Bölüm 7: Mimari Yetenek Çerçevesi (Capability Framework)

Kurumdaki mimari yeteneğin kurulması ve işletilmesi için gerekli süreçler, yetenekler, roller ve sorumluluklar bu bölümde yer alır.

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.