SOA’nın Hakimi Olmak (SOA Yönetişimi)

SOA bir takım teknolojileri tanımlayan, modelleyen bir kavram değil. Aksine teknolojilerden bağımsız, tamamıyla işe yönelmiş bir mimari model. Tüm SOA sürecinde de teknoloji en son sahnede yer alan kısmı oynuyor.

Süreç kabaca şöyle işliyor. Servis Mimarisi akılda tutularak iş süreçlerinizi ele alıyorsunuz, büyük resminizi çiziyorsunuz. Burada doğrudan bir BPM uygulaması yer alabileceği gibi sizin belirlediğiniz ve modellediğiniz senaryolar bütünü de olabiliyor. Örneğin B2B işlerinizi modellediğiniz süreçler. Sonrasında bu süreçlerinizde ihtiyacınız olacak servislerinizi, bu servislerin ihtiyaçlar doğrultusunda etkileşimlerini (orkestrasyon) tasarlıyorsunuz. Bu servisleri kategoriler altında düşünmek mümkün. Muhasebe Servisleri, Finans Servisleri, kimlik doğrulama, hesaplama gibi işleri yapan Destek Servisleri gibi…

Bundan sonraki adımlar ise bu servislere ilişkin kontrat (Contract) denilen, servislerin kullanımına ilişkin kısıtlamaları (SLA – Service Level Agreement) belirten politikaların hazırlanması, test senaryolarının oluşturulması ve en nihayet bu servislerin teknik olarak implementasyonu şeklinde ilerliyor.

Buraya kadar anlattığım özet SOA sürecinin amacı, hem servis mimarisinin tasarımında hem de bu mimarinin işletilmesinde ortaya çıkan bağımlılıklar bütünlüğünü ortaya koyabilmek. SOA eğer gerçekten işleri daha doğru ve daha hızlı gerçekleştirme vaadini yere getirecekse, tüm bu yaşam döngüsü içinde oluşan değişimlere de hızlıca ve en doğru şekilde adapte olmalı. Örneğin, eğer bir iş sürecinde yer alan doküman doğrulama işi yeniden elden geçiriliyorsa ve bazı değişikliklere gidilmesi öngörüldüyse, bu işi gerçekleyen servisin hangisi olduğu, bu servisin hangi diğer işlerin elementi olduğu gözlemlenebilmelidir. Bunun sonucunda olası değişikliğin hangi işleri etkileme olanağı olduğu görülmeli, değişiklikler buna göre yapılmalıdır.

Teknik açıdan bakılırsa servislerden sistemlere doğru bir bağımlılık da görülebilir. Örneğin bir veritabanı sisteminde yapılacak bakım çalışması hangi servislerin çalışmasını engelleyecek ya da aksatacaktır? Başka bir deyişle servislerimin taşıdığı risk tam olarak nedir? Benzer durumlar kontratlar için de geçerlidir. Hangi kontrat hangi servisler için kullanılmaktadır?

İşte tüm bu soruların cevabına heran ulaşabilmek, SOA’yı doğru şekilde kuruma kazandırmak için ortaya çıkmış bir kavram SOA Yönetişimi (SOA Governance).

İş kullanıcısı açısından bakarsak bir SOA Yönetişim aracı şu sorulara cevap verebilmelidir:

• Servislerim nelerdir?
• Servis politikalarım nelerdir?
• SOA ortamımın riskleri nelerdir?
• İş süreçlerim, bunların kullandıkları servislerim nelerdir?
• İş süreçlerime ilişkin riskler nelerdir?
• Kurum içi ve kurum dışı servislerim nelerdir?
• …

Teknik kullanıcı için de şu sorulara cevap vermek önemlidir:

• Servislerim hangi ürünleri ve teknolojileri kullanır?
• Servislerimin bağımlı olduğu sistemler nelerdir?
• SOA ortamıma ilişkin metaverilerim (WSDL, XPDL, BPEL vb) nelerdir?
• Hangi tüketici hangi servisimi ve bu servisimin hangi versiyonunu tüketir?
• Servis politikalarım nelerdir? Bu politikalar düzgün çalışmakta mıdır?
• Servislerim (ya da süreçlerim, uygulamalarım vb) hangi aşamamadır? Tasarım, test, ürün?
• …

Bu sorulardan yola çıkılarak SOA Yönetişiminin sağlıklı bir “SOA Gelişimi” için ilk adımlardan itibaren ortamda mevcut olması gerekliliği görülebilir. SOA’nın, bir kere implemente edilip bir daha dokunulmayan ya da sadece yazılım bazında güncellemeleri olan bir ürün olmaması, sürekli gelişen ve “değişen” bir “iş mimarisi” yaklaşımı olması da SOA Yönetişimini önemli kılmaktadır.

Bir SOA Yönetişim aracının yapıtaşlarını iTKO’nun bu post’unda görmek mümkün. Buna göre bir SOA Yönetişim aracı şu kısımları içerir:

Registry/Repository: Servisler ve ilişkili nesnelerin haritasını tutan bir Registry ve bunlara ilişkin metaveriyi depolayan, sunan bir Repository.
Politikalar: Servislere ait kontratları saklayan ve işleten bir kısım.
Test: Servislerin sağlıklı çalışırlılığını test eden araçları sağlayan bir kısım.

Bu üç kısımdan Registry/Repository SOA Yönetişimin temel parçası olmakla beraber, diğer iki parça ana parçayla entegre çalışabilen ayrı parçalar (ürünler) da olabilmektedir.

SOA Yönetişim araçlarında aranması gereken önemli bir özellik JAXR gibi diğer SOA ürünlerinin entegrasyonuna izin veren standartları destekliyor olmasıdır. Örneğin bir BPM çözümü doğrudan süreçlerine ait proseslerini, bu süreçlerin kullandığı servislerin listesini SOA Yönetişim aracına kayıt etme imkanına sahip olabilmelidir. Bu amaçla mevcut SOA Yönetişim ürünleri geniş komüniteler dahilinde geliştirilmeye çalışılmaktadır. Bunlara örnek olarak Centrasite komünitesini ve Systinet‘i verebiliriz.

Son olarak Gartner’ın SOA projelerinin başarısız olmasının temel nedenlerinden biri olan SOA yönetişim eksikliği hakkındaki şu yazısını okumanızı tavsiye ediyorum.

Related posts:

1. Güzel Zamanlama
2. CETURK’den Java Teknolojileri Etkinliği