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