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