Sayfalar

Şirketiniz İçin SOA



               Günümüz iş ortamı hiç olmadığı kadar rekabetçi. Yaratıcı iş modelleri, geleneksel ve yeni nesil rakipler, hizmet kanallarının çeşitliliği, sürekli artan kalite ihtiyacı,  yeni uyumluluk gereksinimleri  ve artan maliyet baskıları CEO’ların  gündemini sürekli olarak meşgul ediyor. Sürekli yeni fikirler üretebilen ve fikirlerini çok hızlı markete sunabilen,  esnek, çevik ve  tepkisel bir şirket olabilmek her CEO’nun hedefi. İçsel ya da dışsal dinamiklerden doğacak taleplerin hayata geçirilebilmesi için de zaman eskiye görece çok daha kısıtlı. Oysa, yeniliklerin zamanında pazara sunulamaması  çoğu kez pazar  kaybıyla eşdeğer.
Tüm bunlar, doğal olarak fikirleri hızlıca hayata geçmesini sağlayacak teknolojilere olan ihtiyacı ve bu teknolojileri sunmakla görevli IT birimleri üzerindeki yükü hiç olmadığı kadar arttırmaktadır. Doğru teknoloji kullanımının stratejik önemi  giderek artmakta ve dijital iş dünyası ile gerçek dünya arasındaki sınırlar giderek ortadan kalkmaktadır.
Dolayısıyla, artık şirketler içerisindeki IT departmanları, İş departmanları ile çok daha uyumlu ve birebir çalışmak durumundadır.  IT departmanlarının taleplerin sürekliliği ve artan yoğunluğu ile başa çıkabilen, gelen talepleri hızlıca ve kurum içerisinde en az etki ile hayata geçiren bir yapıya adapte olması için yeni yaklaşımlar gerekmektedir. Servis odaklılık yaklaşımının mimari yansıması olan Servis Odaklı Mimari (SOA: Service Oriented Architecture) işte bu değişen iş ortamının gereklerini karşılamak için ortaya çıkmış, bir kurumsal mimari modelidir.
Forrester ve Gartner gibi firmalarca yürütülen araştırmalar SOA’den vaad edilen sonuçları alabilen firmaların, SOA’i bir kurumsal mimari modeli ve stratejik dönüşüm yaklaşımı olarak ele alan firmaların etkin sonuçlar elde edebildiğini gösteriyor. SOA’nin ciddi bir dönüşüm gerektirdiği, ancak aynı zamanda küçük, dikkatli adımlarla giden ve artarak ilerleyen bir süreçle ele alınması gerektiği muhakkak. SOA’nın vaad ettiği faydaların, gerçekleştirim sürecinin giderek olgunlaşmasıyla artarak devam ettiği göz önüne alınırsa, SOA’i sadece bir teknoloji olarak algılayıp, stratejik bir vizyondan yoksun olarak yola çıkan firmaların, büyük resmi kaçırmaları ve beklenen faydaları görememeleri, doğal bir sonuç olarak algılanmalıdır.
Bu yazıda servis odaklılık kavramları, iş dünyasına yansımaları ve stratejik SOA dönüşümlerinin nasıl ele alınması gerektiği üzerinde durulmuştur.



Servis Nedir?

Servis odaklı yaklaşımının temeli, doğal olarak servis kavramıdır. Bir servis, tutarlı bağlam çerçevesinde, birbirine uygun bir gurup tekrarlanabilir operasyondan oluşan, iyi tanımlanmış standard bir arabirime sahip, kavramsal bir bileşen olarak tanımlanabilir.
Dijital servisler gerçek dünyadaki oluşumların iyi tariflenmiş birer yansıması gibidir. Hemen hemen herkesin elektirik, su veya iletişim sağlayan şirketler ile bir müşteri olma hikayesi olmuştur. Bu firmalara işlemleriniz için uğradığınızda sizi “Müşteri Hizmetleri Birimi”’ne yönlendirirler. “Müşteri Hizmetleri Birimi” müşteriler için olası tüm operasyonları tek noktadan sunarak genel işleyişte bir verimlilik hedefler. Bu birimi SOA’de bir digital servis olarak tarifleseydik,  “Müşteri Servisi” yaratıp,  bu servise bağlı olarak da  “Müşteri Bilgilerini Getir”, “Yeni Müşteri Yarat”, “Müşteri Bilgilerini Güncelle”, “Abonelik Sonlandır”   gibi uygun operasyonlar tanımlayabilirdik.
Daha teknik bir örnek olarak bir yazıcı ünitesinin işlevlerini servis olarak tanımlamayı kullanabiliriz. “Yazıcı Servisi” muhtemelen “Belgeyi Yazır”, “Duraklat”, “İptal Et”, “Kapan”,”Açıl”,”Uyku Moduna Geç” gibi  operasyonlar içerecektir.
Gerçek dünyada bulunan nesneleri bir servis olarak kavramlaştırmanın en kolay yolu, o şeyi bir kara kutu olarak düşünmek ve dışarıdan aldığı direktif ve bunlara cevaplarını birer operasyon olarak tanımlamaktır. Örneğin bir iş biriminine organizasyon yapısı, iş süreçleri ve benzeri karmaşık yapılarından sıyrılarak dışarıdan baktığımızda ne gibi işlevleri yerine getirdiğini kolayca servis olarak tanımlayabiliriz.  
SOA’nin ortaya çıkışına yol açan en büyük neden,  sık yaşanan değişimlerin etkilerini minimize etmek gayreti olarak tanımlanabilir. Bir başka deyişle, değişikliğe gittiğiniz bir nesnenin zincirleme değişiklikler reaksiyonuna yol açmasının önünü kesmek çabası olarak da nitelendirilebilir. Eğer bir bileşenin kendi görevlerini yerine getirmesi için bir diğer bileşenden faydalanması gerekiyor ise, bu ilişki bir bağlanım (coupling)  olarak nitelendirilir. Satış departmanının bir satış işlemini tamamlaması için stok, lojistik ve muhasebe gibi departmanlara duyduğu ihtiyaç bir bağlanım örneğidir. Lojistik deparmanının mal teslimi için kabul formlarında yapacağı değişikliğin satış departmanı tarafından öğrenilmesi ve kendini buna göre adapte etmesi çalışması ise değişim etkisine (change impact) iyi bir örnektir.
Bir başka bağlanım örneği olarak iş süreçlerinin içerisine dahil edilen bir tedarikçi firma düşünün. İş süreçlerinde bu tedarikçi firmaya ihtiyaç duyan her şirket içi iş birimi ile tedarikçi arasında bir eşleme oluşturacaktır. Şimdi bu eşleme ilişkisinde doğal olarak tedarikçi ile olan ilişkiler, tedarikçinin gereksinimleri temin etme şekli (formlar, sipariş alma, durum takibi vb) ve diğer faktörler önemli olacaktır. Markette alternatifler oluşması ile tedarikçi sayısının zamanla arttığını düşünün. Her tedarikçi yeni ilişkiler, formlar, iş süreçlerini beraberinde getirecektir. Bir tedarikçinin değiştirilmesi zorunluluğu doğduğu zaman,o tedarikçi ile uyumluluğunu pekiştirmiş tüm iş birimlerinden homurtular yükselecektir.  

Klasik yaklaşımda mevcut tedarikçiler ile sıkı bir ilişki içerisinde bulunulduğundan, her entegrasyon noktasında her yeni tedarikçi ile bir adaptasyon süreci yaşamanız zorunluluğu vardır. Bu adaptasyon için harcayacağınız enerji değişim etkisine bir başka örnek teşkil eder Değişim etkilerinin yüksek olduğu bir şirkette alınan her karar, yapılacak her değişiklik büyük efor ve zaman gerektireceğinden, şirketin hareket kabiliyeti doğal olarak kısıtlanır. Böyle bir durumda şirketin esnekliğinden ve çevikliğinden söz edilemez.
SOA, bu durumdan kurtulmak için bağlanım ilişkisinin  gerçekleştirimler yerine sözleşmeler üzerinden kurulması ilkesini getirir (gevşek bağlanım).  Servisler amaçlarını, sundukları yetenekleri, servisin nasıl kullanılacağını, mesaj yapılarını ve diğer özelliklerini bir servis sözleşmesi ile olası istemcilere sunarlar. Servisi alan taraf yani istemci, hizmetin nasıl ve kim tarafından sunulduğu ile değil, sunulmuş olan standart sözleşme ile bağımlıdır. Sözleşme yerine getirildiği sürece sözleşmenin arka planında olup biten değişiklikler istemciye yansımaz.

Tedarikçiler örneği için şirketlerin genellikle izlediği yol bir satın alma departmanı kurup iş birimlerinin taleplerinin standard yollar ile toplamaktır. Yeni tedarikçi ekleme ya da tedarikçi değişikliği örneğini ele alacak olursak servis odaklı bir şirket tedarikçi değişikliğini hemen hemen hiç hissetmeden, sadece satın alma biriminde küçük adaptasyonlar ile yapabilecektir. İşte bu SOA’nin vaad ettiği esneklik ve çevikliğin en önemli örneklerinden birisidir.
IT içinden bir örnek verecek olursak, "mainframe" uygulamaları gibi geleneksel uygulamaların açık sistemlere taşınması sırasında oluşacak etkiyi ele alabiliriz. Gerçekten de bu örnek pek çok CIO’nun başını ağrıtan bir sorundur. Tüm uygulamalar baştan sona günün gereklerine göre yeniden yazılabilir. Ancak değişmeyen tek şey değişim olduğundan, bir süre sonra yeni teknolojilerin ortaya çıkması ile bu teknolojilere adaptasyon gerekeceği aşikardır. Bu durumda oyunu tekrar baştan kurup, yeni baştan her şeyi ele almak gerekecektir. SOA bize bu noktada kavramsal düzeyde stabil olanı tanımlamayı (Servis Sözleşmeleri) ve tüm bağımlılıkları değişmesi muhtemel bileşenler yerine, daha stabil kavramlara doğru yapmamız gerektiğini söylemektedir. Bir yazılımın arabiriminin (servis ve operasyon tanımları), arabiriminin nasıl gerçekleştiğinden  (operasyonların programlama dili ile kodlanması) daha stabil olduğundan biliyoruz.Bu sebeple, gerçekleştirimler yerine arabirimlere kurulacak  bağlanım ilişkileri, bağımlı olan taraftaki değişiklik etkisini azaltır.  Şu halde,  SOA’e göre yapılacak şey aşikar olarak tüm bağımlılıkları iyi tanımlanmış servis arabirimleri üzerine çekerek arka plandaki değişiklikler için hareket kabiliyeti kazanmaktır. Bu sayede servislerinizin gerçekleştirimlerini bugün açık sistemler üzerine taşırken, yarın bulut sistemlere taşımanız ve arka plan kodlarınızı yenilemeniz hissedilmeyecek bir etki ile gerçekleşebilir.
SOA oluşturma stratejisi olarak servis sanallaştırma (Service Virtualization) ve  servis otobüsü (Enterprise Servise Bus)  gibi taktikler kullanmanın kurumsal değişimlerde etki indirgemenin en önemli araçlarından olduğunu da konuya yakın olan okuyucular için bir not olarak düşelim.

Servis Odaklı Dizayn Prensipleri

               Service odaklılık, bir dizi dizayn prensibinin uygulanmasını birlikte getirir. Bu yazının amacı her ne kadar bu prensiplerin detaylarına girmek olmasa da konunun daha iyi anlaşılması açısından genel kabul görmüş bir dizi prensibe değinmekte fayda var.
-        Servis Sözleşmeleri (Service Contracts) : Servisler amaçlarını, sundukları yetenekleri, servisin nasıl kullanılacağı, mesaj yapılarını ve diğer özelliklerini gösteren bir servis sözleşmesi ile sunarlar. Bir servisi kullanacak her türlü servis istemcisi bu sözleşmeye göre hareket eder. Servis sözleşmeleri istemciler tarafından kolayca yorumlanabilir ve standart şekilde olmalıdırlar.
-        Gevşek Bağlanım (Loose Coupling): Servis istemcilerinin servise olan bağımlılığı sadece servis sözleşmesinedir. Servisin iç işleyişinin nasıl olduğu, nasıl gerçekleştirildiği servis istemcilerini bağlamaz. Bu ilke gevşek bağlanım olarak adlandırılır.
-        Kavramsallaştırma (Abstraction – Conceptualization): Kavramların,  özelliklerinin ve davranışlarının tanımlanmasına biz kavramsallaştırma diyoruz. Bir başka deyişle kavramsallaştırma, bir servisin, servis olmasını sağlayan şeylerin tanımlanmasıdır diyebiliriz. Kavramsallaştırma yapılırken servis isimlendirmesinin ve servis içerisinde tanımlanan yeteneklerin birbirleriyle uyumu da (cohesion) son derece önemlidir. Bir servisin tanımlanması esnasında (encapsulation)  yine servis istemcilerini ilgilendirmeyen gereksiz ayrıntıların sözleşmeye konmaması (information hiding) dikkat edilmesi gereken bir başka husustur.
İyi tanımlanamamış servislerin ideal formlarına  kavuşuncaya kadar değişiklikler görmesi beklenen bir durumdur.Bu sebeple tanımlamalar dikkatlice ve ideal durumlarına göre yapılmalıdır.
-        Yeniden Kullanım (Reuse): Çalışma mantığı servislere ve operasyonlara dağıtılarak yeniden kullanımlarının özendirilmesi.
-        Keşfedilebilirlik (Discoveribility): Servis sözleşmeleri kullanımı beklenen hedef kitle tarafından kolayca erişilebilir olmalıdır. Bu nedenle, servis sözleşmeleri hedef kitle tarafından erişilebilen servis kayıt defterlerinde kayıt altına alınarak olası istemciler tarafından keşfedilebilmesi sağlanır.  
-        Otonomi (Authonomy): Servisin yeteneklerini kesintisiz ve güvenilir bir şekilde sunabilmesi için kullandığı kaynaklar üzerinde tam otoritesi olmalıdır.
-        Birleştirebilirlik (Composibility): Servisler başka büyük problem çözümlerinde kullanılabilirler. Bileşimin boyu ve büyüklüğüne bakılmaksızın servisler aktif çözüm bileşenleri olarak tüketilebilirler.
-        Durumsuzluk (Statelesness): Durum servis operasyonlarının aynı istemci tarafından ardışıl kullanıldığı durumlarda iki operasyon kullanımı arasında istemci kullanımına özel verilerin saklanmasına verilen addır. Bu, servisin çalışırlığını ve genişleyebilirliği etkileyebileceğinden servislerin mümkün olduğu kadar durumsuz tasarlanması gereklidir.

SOA prensipleri sadece teknoloji odaklı düşünülmemelidir. Yukarıda geçen tüm prensipler iş dünyası da dahil etkileşim içerisinde bulunan nesnelerin bulunduğu her ağ için uyarlanabilir ve kullanılabilir prensiplerdir.

İş Yaşamında Servis Odaklılık

               Yüksek düzeyde iş uzmanlığı gereksiniminin olduğu bir çağda yaşıyoruz. Şirketlerin  temel işlevlerine daha iyi odaklanabilmesi için, "iş süreçleri içerisinde kendi alanları dışında kalan  pek çok görevde  bir iş ortağı ile hareket etmesi" genel kabul gören bir eğilim.
               Bu eğilim özellikle üretim sektöründe yıllardır çok ağırlıklı olarak kendini göstermektedir. Aynı yöntem hizmet sektörü tarafından da daha sonradan takip edilmeye başlamıştır. Taşımacılıktan tutun da insan kaynakları yönetimine kadar pek çok alanda iş ortaklarından alınan uzman taşeron ya da tedarik hizmetleri bugün şirketlerin iş süreçlerine çeşitli seviyelerde entegre olmuş  durumda. İş süreçleriniz içerisindeki görevleri, alanında uzman bir iş ortakları ekosistemine dağıtmak, şirketinizin enerjisini ve konsantrasyonunu asıl değer yaratan işlevlerine kaydırması için mükemmel bir yol olduğu gibi, maliyetlerin düşürülmesi ve verim artışı için de aynı ölçüde önemlidir. Yeni başlangıç şirketleri için de çevrelerindeki bu ekosistemden faydalanmak, kendi bünyelerinde ancak çok uzun yıllar içinde edinebilecekleri mükemmel hizmet seviyelerini,  başka şirketlerden hizmet olarak hazır halde alabilmeleri demektir.
 Şirketler kendi iş süreçlerini dış kaynaklardan hizmet alarak optimize ederken, aynı zamanda başka şirket ve/veya bireyler açısından da hizmet sağlayıcı rolüne bürünmektedirler.  Şirketlerin  iş ortakları, müşterileri, devlet gibi ortam düzenleyiciler ve diğer partiler ile olan ilişkileri hizmet alıp vermeye dayanan bir çeşit ağa  benzetilebilir.

Tek bir şirket perspektifinden bakıldığında çok daha karışık bir ağ modeli yine şirketlerin iç işleyişinde de karşımıza çıkar. Bir şirket kendisini oluşturan iş birimleri ve bu iş birimleri tarafından yerine getirilen hizmetlerin bir toplamı olarak görülebilir. Bu hizmetlerden kimileri direkt olarak müşterilere sunulurken, belki sayıca çok daha fazlası da bu hizmetlerin yerine getirilebilmesi için gerekli olan hizmetler şeklindedir. Bir otomotiv firmasını ele alacak olursak bu firmanın en temel hizmeti satış ağı üzerinden müşterilerine araç sağlamak iken, bu hizmetin yerine gelmesi için şirketin iç dünyasında satış, tedarik, üretim, muhasebe ve daha pek çok iş birimi, çok sayıda karmaşık işlevler yerine getirmektedirler.
              
Bu hizmet alıp verme ilişkisinde, hizmeti sunan (kurum ya da iş birimi) perspektifinden dışarıya sunulan her yetenek,  amaçları, standartları ve diğer özellikleri ile tanımlandığında iş servislerini oluşturur. İş yaşamında servis odaklılık şirket yeteneklerinin, nasıl gerçekleştirildiklerinden bağımsız bir düzeyde servisler olarak tanımlanması, yayımlanması ve tüm olası servis istemcilerine etkin bir şekilde sunulmasıdır. Bir iş birimi gibi belli bir perspektiften bakıldığında dış dünyaya sunulan yetenekler ve bu yeteneklerin yerine getirilmesi  için gerekli destek yetenekleri,  iş servislerinin kalbini oluşturur. Bu servislerin yazılımlar olarak tanımlanması da dijital iş servislerini oluşturmaktadır.  Şüphesiz ki, iş servislerini dijital dünyaya taşımak, bir şirketin yeni dünyaya adaptasyonu için şarttır. Servis odaklı bir dönüşüm,  şirketlere servislerini sınırsız sayıda kanaldan, sınırsız iş ortağı ve müşterinin hizmetine  sunma kabiliyeti kazandıracaktır.

Servis Tipleri

               Bir şirkette  var olan tüm servisler aynı seviyede değerlendirilemez. Dizayn prensiplerinden hatırlayacağınız üzere servisler başka servislerin oluşumunda katılımcı olarak yer almaktadırlar. Servisleri bu bileşim şekli açısından bir hiyerarşiye oturtacak olursak, en üst seviyede şirketin iş alanları ile bire bir eşlenmiş iş servisleri koyarken, daha alt seviyelere doğru ortak işlevsellikleri sunan servisleri, üst seviye servislerin oluşumu için teknik destek veren uygulama servislerini ve altyapı görevleri için altyapı servislerini konumlandırabiliriz. 

               Servisler üst seviyeye doğru gidildikçe, alt seviye servislerinin bir kompozisyonu ile oluşurken, alt seviyelerde daha fazla atomik yani başka servise ihtiyaç duymadan çalışan bağımsız servisler göze çarpar.
               İş servisleri, bir şirketin yeteneklerinin (iç ve dış) dijital dünyaya birebir yansıması olarak algılanabileceğinden, SOA dünyasındaki en önemli servisleri oluştururlar.  İşin aslı daha alt seviyedeki servisler hazırlanmadan iş servislerinin oluşturulabilmesi de zordur. Ancak iş departmanları ve IT’nin bir masa etrafında konuşacağı, servis seviyelerinin iş indikatörleri ile eşleşeceği servisler ağırlıklı olarak iş servisleri olacaktır.

SOA Sadece Servisler Dünyasından mı  İbaret?

               Kurumsal SOA projelerinden bahsedilirken, SOA kavramlarının içerisine çoğunlukla başka mimari stiller, eğilimler ve teknolojilerin de dahil edildiğine şahit olabilirsiniz. Bunun sebebi  SOA’nin yeni nesil yaklaşımlar için bir temel teşkil etmesi, çoğu için katalizör olmasıdır. SOA şirket içerisindeki dağıtık yeteneklerin iyi tanımlanmış arabirimler olarak, standard yöntemler ile kullanıma sunulmasıdır.  Kuruma adapte edilecek her yeni yaklaşım bu yeteneklerden en efektif şekilde faydalanma yoluna gidecektir.
Kurumsal çapta veya daha küçük çaptaki projelerde uygulanan katıksız tek bir yaklaşımdan bahsedilemez. Çoğunlukla çeşitli teknolojiler ve mimari stillerin uyumlu bir bileşimi bir arada uygulanır.  SOA genellikle uygulanan yaklaşımların en öne çıkanı olmasından dolayı, bir şemsiye görevi gören ve anıldığında adı  bir kaç yaklaşımı daha bir arada düşündüren bir kavram.
               Bu yaklaşımların en önemlilerinden biri olan ve genellikle SOA ile birlikte anılan süreç yönelimli mimari (BPM:  Business Process Management) bir sistemi süreçler, alt süreçler ve aktiviteler olarak görür. Servisleri bir sistemde bulunan yeteneklerin tanımlanması ve kullanımı için etkin bir yöntem olarak tanımlarsak, süreçler sistem içindeki bu servislerin ve iş gücünün orkestrasyonudur diyebiliriz.  Bir süreci oluşturan aktiviteler, sistem içerisinde bulunan servis operasyonları tarafından yerine getirilir. Bir sistemin içerisinde bulunan tüm yeteneklerin kataloglanmış servisler halinde bulunması, süreçlerin oluşturulmasını ve hayata geçirilmesini son derece kolaylaştırır. Bir kurumda süreçlerin hazır halde olması halinde ise (en azından kavramsal düzeyde), sistemde gereksinim duyulan servislerin  daha rahat  tespit edilebilmesini sağlar. Bu nedenle bu iki yaklaşımın hemen hemen her zaman bir arada kullanımı son derece doğal ve gereklidir. Çok beğendiğim bir analoji bu iki yaklaşımı fıstık ezmesi ve reçele örneği ile ele almaktaydı. Ayrı ayrı da tüketebilirsiniz ancak bir arada mükemmel olurlar. 
               Yazılımlar açısından bakıldığında süreç yönelimli mimari iş akışı mantığının gömülü kod parçalarından ve insanların zihinlerinden (ya da masalarına asılı post-it’lerden) sıyrılarak tanımlı ve kontrollü bir şekilde işletilmesidir. Yazılımların sadeleşmesini sağladığı gibi, yazılımları kullanan insan gücünün de etkin kontrolünü, takibini ve bilgilendirmesini sağlar.
Bir sistemdeki iş süreçleri, genellikle uzun süreli olup, süreç içindeki aktiviteleri ve insan teknoloji etkileşimlerini kontrol eder. Bir satış sürecini ele alacak olursak sipariş alma, ödeme alma, tedarik etme, muhasebeleştirme, lojistik gibi alt adımlar bazen aylara yayılmış bir zaman diliminde tamamlanabilir.
               SOA ile giderek daha fazla birlikte anılmaya başlanan Olay Yönelimli Mimari’nin (EDA: Event Driven Architecture),  eskiden beri pek çok uygulamada  kullanılan bir stil olduğu  halde, kurumsal mimari düzeyinde etkisinin artması daha yakın zamanlarda olmuştur.  EDA ve SOA’nin bir arada bulunduğu stil kimi yazarlar tarafından SOA 2.0 olarak adlandırılmaya başlanmıştır.
Ancak başta da söylediğimiz gibi mimari stiller çoğu zaman bir arada uygulanabilirler ve bu açıdan bakıldığında kafa karıştırıcı numaralandırmalar yerine bir mimaride uygulanan yaklaşımları tek tek belirtmenin çok daha açıklayıcı olacağı söylenebilir. Bu tarz isimlendirmelerin teknik gerekçelerden çok pazarlama amaçlı türetildiğini düşünüyorum.
               EDA, sistem içindeki bileşenlerin , aldığı olay yada olaylar bildirilerine tepkisel olarak aksiyonlar işletebildiği bir mimari stildir. Sistem içerisinde oluşan olaylar, olay kaynakları tarafından yayınlanır ve olay gözlemcilerine ulaştırılır. Dinleyici konumundaki olay gözlemcileri oluşan olaylar kendilerine ulaştığı anda bir aksiyon alırlar.  Alınacak aksiyonun ne olacağı ve işletilecek mantık olay gözlemcisinin otoritesi altındadır.
               SOA bir sistemdeki yeteneklerin resmedilmesi ve kullanımının mükemmel bir yolu olarak görülebileceğinden, sistemde oluşacak olaylar sonucu alınacak aksiyonların hazırlanmasını son derece kolaylaştıracaktır. Bir mimaride EDA’nın da kullanımı sistemin daha proaktif, tepkisel ve çevik olmasını sağlayacaktır. Buzdolabınızda peynirinizin bittiğini farkedip, üzerinizi giyip marketten peynir almanız tembellik yapmak istediğiniz bir Pazar sabahında sizi sıkabilir. Buzdolabınızın peynirin bittiğini kendi kendine fark etmesi, en yakın marketten istediğiniz markayı sipariş vermesi  güzel olmaz mıydı?
               SOA şemsiyesi altında anılan yeni nesil yaklaşımlar ve teknolojilerin incelenmesi uzun bir konu. En önemli iki yaklaşım olan BPM ve EDA’ı kısaca ele aldıktan sonra, diğer yaklaşımlardan bazılarına da kısaca değinmek gerekir ise:
·        BRM (İş Kuralları Yönetimi -  Business Rule Management):
Sistem içerisindeki sık değişen iş kurallarının (örneğin vergi oranları, kar oranı, hesaplama sabitleri vb) servis gerçekleştirimlerinin içerisinde gömülü olarak tutulması yerine, ayrı bir noktada tanımlanması, kural erişimlerinin ortak bir servis üzerinden sağlandığı, kural değişikliklerinin anında tüm sisteme değişiklik gereksimi olmadan yansıtılabildiği bir yaklaşım olarak nitelendirilebilir. Bir sistemde BRM kullanımı tüm servislerin stabilitesini arttıracaktır.
·        PDA (Politika Yönelimli Mimari – Policy Driven Architeture)
Sistem çalışma politikalarının yine gömülü kodlardan sıyrılarak dış bir ortamda tanımlanmasıdır. Sistem bileşenleri ve servislerin gerekli zamanlarda servisler üzerinden bu politikaları okuyarak davranışlarını düzenlemeleri hedeflenir.
·        ESB (Kurumsal Servis Otobüsü)
İstemciler ile sunucular arasında bire bir bağlanım  yapmak yerine, ek bir ara katman üzerinden konuşulmasını sağlayarak servis alınan noktaların istemcilerden tamamen gizlenmesi yaklaşımıdır. Bu yaklaşım, yapılan toplam bağlanım sayısını indirgeyeceği gibi karmaşık entegrasyon sorunlarını da istemcilerden gizleyecektir. İstemciler standart yöntemler ile ESB ile konuşurken, ESB geri planda farklı protokol ve servis sağlayıcılar ile haberleşebilir. Aslında “Servis Nedir?” bölümünde anlatılan iş birimleri ile tedarikçi ilişkilerinin bir satın alma departmanı standartlaştırılması bu yaklaşımın iş yaşamına uyarlanmasının güzel bir örneğidir.
·        Aspect Oriented Arhitecture (Cephe Yönelimli Mimari)
Çok  sayıda bileşen ya da servisi ilgilendiren ortak çalışma mantıklarının bu bileşen yada servisler içerisinde tek tek ele alınması yerine, tek bir noktada oluşturulması ve tüm ilgili noktalarda çalıştırılmak üzere  otomatik enjeksiyonudur. Bu, filtreleme yöntemleri ile uygulanabildiği gibi, otomatik kod oluşturma teknikleriyle de yerine getirilebilmektedir. Servis erişimlerinde tek tek erişimi yapan istemciler hakkında güvenlik kontrolü yapmak yerine, ortak bir katman üzerinde (örneğin ESB) bu kontrollerin tamamlanarak servislerin yüklerinin hafifletilmesi ve sadece güvenli isteklerin servislere erişiminin sağlanması bu yaklaşıma iyi bir örnektir.

Stratejik Bir Yaklaşım Olarak SOA

               Servis odaklı dönüşüm stratejinizi nasıl oluşturacağınıza geçmeden önce hayal gücünüzü biraz daha canlandırmak için servis odaklılık dönüşümünü tamamlamış bir şirketin yaşamını kısaca tasvir etmek istiyorum. Varsayımsal şirketimizin adı “Çevik Servisler A.Ş.” olsun ve kısaca ÇS diye analım.
ÇS şirketi, şirketin bütününü oluşturan tüm iş bileşenlerini (yeteneklerini) tanımlamış ve kategorize etmiş olduğundan, ÇS şirketi üst yönetimi stratejik kararlar alırken, şirket iş modeli haritasından faydalanarak hangi iş bileşenlerine ve iş süreçlerine etki edeceklerini rahatlıkla görebilmektedir. ÇS şirketinde bir iş bileşeni altında yatan süreçler, iş servisleri bunları destekleyen yazılımlar ve altyapılar bilindiğinden yeni stratejilerin getireceği değişiklikler bütün birimler tarafından hızlı bir biçimde algılanmakta ve gerekli değişiklikler çok hızlı projelendirilip yerine getirilebilmektedir.
ÇS şirketi yöneticileri, iş servisleri ve iş süreçleri hakkında sürekli gözlem yapma ve performans indikatörlerini sürekli takip edebilme imkanına sahiptir. Örneğin geçen ay başında yapılan sipariş  alma sürecindeki iyileştirmenin, iş gücü üzerinde %10’luk bir tasarruf sağladığını görmek, şirket CEO’sunu oldukça neşelendirmiştir. İş süreçleri ve iş servislerinden toplanan bilgilerin, dengeli kurum karnesinde sürekli görünür hale gelmesi, personel performans takibini de son derece kolaylaştırdığından İnsan Kaynakları Müdürü  de çok memnundur ve katıldığı tüm platformlarda geldikleri noktayı göğsünü gere gere anlatmaktadır.
 ÇS şirketinin müşterilerine ve iş ortaklarına sunduğu iş yetenekleri yazılım servisleri halinde kataloglandığından pek çok kurumsal müşterisi ve iş ortakları ÇS servislerini kendi sistemlerine entegre etmiş durumdadır. En büyük kurumsal müşterilerinin siparişlerini kendi sistemleri üzerinden açmaya başladığından beri satış departmanının yükü bir hayli hafiflemiştir. Bu müşteri hesabının yöneticisi sürekli yaşadığı telefon trafiği bittiği için çok mutludur, artık müşterisine sadece haftada bir kahve ziyareti için uğramaktadır.
ÇS iş servislerini self servis kanallarından müşterilerine aracısız sunmaktadır. Yeni hazırlanan cep telefonu yazılımlarını, sadece cep telefonu ara yüzlerinin tamamlanarak mevcut servisleriyle  bir ay gibi kısa bir sürede hayata geçmesi şirket CIO’sunu çok gururlandırmıştır.
CIO, tüm servislerin ESB üzeriden erişimine karar vererek  ne kadar isabetli bir iş yapmış oldukları  yeni muhasebe programının  entegrasyonu sırasında bir kez daha görmüştür. Yeni muhasebe yazılımının servislerini, hızlıca kendi muhasebe servislerine adapte etmişler ve diğer yazılımların da hiçbir şeye dokunmamışlardır.
Stokların azalmasını takiben otomatik satın alma siparişlerinin açılır hale gelmesinden beri satın alma departmanı da, iş yükünü hafifletmiş,  Satın Alma Müdürü iki senedir ertelediği tatiline nihayet çıkabilmiştir.
Şirket CEO’su, geçen hafta akşam yemeğinde bir araya geldiği, aynı zamanda şirketin de VIP müşterileri arasında yer alan bir arkadaşının, şirketin Antalya şubesine girdiğinde kendisini karşılayan Özel Müşteri Temsilcisinin kendisi hakkında sahip olduğu bilgiler ve gösterdiği ihtimam karşısında nasıl şaşırdığını son yönetim kurulu toplantısında gururla anlatmıştır. CEO'nun arkadaşı elbette yeni hayata geçirdikleri sistemde, VIP müşterilerinin şubeye girişlerinde özel müşteri temsilcilerinin otomatik olarak uyarıldığı ve bilgilendirildiğini bilmiyordur.
                Bu örnek daha da uzatılabilir. Ancak  bu noktadan sonra  ÇS şirketini sizlerin hayal gücüne bırakırken,  tüm bunların bir şirket yaşamında kazara oluşabilecek bir durumlar olmadığını vurgulamam gerekiyor.  Hatta,  servis odaklı olmaya karar vermiş ve tüm yazımlarını modüler servisler olarak hazırlamaya karar vermiş bir şirketin bile, doğru strateji ile hareket etmemesi durumunda arzu edilen duruma ulaşamayabileceğinin altını çizmeliyiz. Böyle bir değişimi gerçekleştirmek, yüksek bütçeli IT yatırımları ve  “just do it” felsefesinden ziyade, doğru bir strateji çizmek  ve bu stratejiyi sabırla uygulamaya bağlıdır. Böyle bir stratejiyi oluşturmak için ise kabaca şu adımları önerilebilir:
1.      Hedefin, gidilmek istenen noktanın belirlenmesi
Stratejik bir SOA programı oluşturmada ilk odaklanılacak yer teknoloji değil, iş modelidir. Şirket için idealize edilmiş bir iş modeli oluşturmak ilk adım olacaktır. Bunun için hali hazırda bulunabilecek endüstri modellerinden ve  uzman danışmanlardan faydalanılarak özelleştirilmiş modeller oluşturmak gerekecektir. İş modeli  şirketi oluşturan yeteneklerin iş bileşenleri şeklinde dekompozisyonu,  süreçler ve bunlar arasındaki ilişkiyi gösterir şekilde olmalıdır. Şirket için hazırlanacak bu idealize iş modeli yazılım, bilgi ve altyapı mimarilerine de yol gösterici olacaktır.
Bu idealize modeller için değer zinciri (value chain) analizleri şirketlerin en önemli süreçlerini, süreçleri oluşturan aktivitelerini (ve dolayısıyla iş servislerini) ortaya koymakta faydalı olacaktır. Ancak şirketlere daha bütünsel bakılmasına yardımcı olan ve tüm iş bileşenlerini (dışarıdan hizmet almak istencekler de dahil) ortaya koyacak,  değer ağı (value net) gibi daha yenilikçi  yöntemler SOA ve servislerin daha rahat tesbiti açısından daha faydalıdır.
Örneğin IBM tarafından geliştirilmiş bir değer ağı  yöntemi olan “Component Business Model” yaklaşımı, şirketi oluşturan iş bileşenlerini belirlemek ve kategorize etmekte yol gösterici olabilir.



Şirket iş birimleri içerisindeki tüm yetenekler iş bileşenlerine ayrıştırılıp, bu yeteneklerin yerine getirilmesi için  servis, insan kaynağı, iş süreçleri, bilgi modeli, olay- sonuç ilişkileri, teknoloji ve sağlıklı izleme ve geri bildirimler için indikatörler belirlenmelidir. Tabii bu iş bileşenleri için birer yönetişim modelinin oluşturulması da bu aşamada daha sağlıklı bir şirket için zemin oluşturur.

Tüm iş bileşenlerinde bahsettiğimiz detayda inilmesi elbette uzun bir zaman alabilir. Mükemmel form bir kerede yakalanamayabilinir. Dolayısıyla,  ilk adım öncelikle şirket yeteneklerinin ayrıştırılması olup, iş bileşenlerinin ve iş bileşenleri arasındaki ilişkilerin belirlenmesidir. Bu temiz bir bakış açısı kazanmak ve yürünmesi  gereken yol için fikir sahibi olmak adına yeterli olacaktır.Detaylandırma çalışmaları diğer çalışmalar ile paralel bir şekilde , zamana yayılmış olarak yürütülebilir.
SOA’de amaçlarımızdan birisi İş ve Teknoloji uyumluluğunu yakalamak olduğundan iş servislerinin, iş bileşenlerininin bir parçası olarak belirlenmesi bu yolda çok önemli bir adım olacaktır.


2.      Mevcut Durumun, Bulunulan Noktanın  Tesbiti
Mevcut iş, yazılım, bilgi ve altyapı mimarilerinizin anlaşılması ileriye doğru atacağınız adımların planlanması için gereklidir. Bir çok şirket mükemmel organizasyona ulaşmak için yıllardır kalite çalışmalarını aralıksız sürdürmekte olduğundan, şirketlerde kolaylıkla dokümante edilmiş iş süreçleri, iş tanımları, görev tanımları ve organizasyon yapısına erişmek mümkündür.  Benzer dokümantasyona veri modelleri, yazılımlar ve altyapı içinde rahatlıkla erişilebilir.

3.      Yol Haritasının Çizilmesi 
Hedef iş modellerinde, iş bileşenleri arasındaki bağımlılıklar ortaya konmuş olacaktır. IT bu noktada sıkı bir çalışmayla iş servislerindeki ortak noktaların tespitini yaparak ve kurumsal politikaları da göz önüne alarak gereken ortak servisleri tespit etmeli,  iş servislerinin oluşturulabilmesi için daha alt seviyedeki teknik servisler belirlemelidir. Alt seviyeli  servisler fazlaca abartmadan ilk geliştirilmesi düşünülen iş servislerini destekleyecek şekilde öncelikli olarak ele alınmalıdır.

İş servisleri arasındaki bağımlılıklar bilineceğinden ve gerekli alt seviye servisler de ortaya konacağından alternatif gerçekleştirim yolları da yaklaşık olarak belirlenmiş olacaktır. Bağımlılıkların ortaya konması doğru yol haritalarının oluşturulabilmesi için şarttır.

4.      Planlama
Gereksinimler ve bağımlılıklar ile ortaya konan alternatif yollardan en akıllıca olanlarının bir plana oturtulması SOA programını hazır hale getirecektir. Politik ortam gereği aksi gerekmedikçe,  en bağımlı olunan servisler en öncelikli gerçekleştirilmelidir. Örneğin müşteri servisi ele alınmadan bir CRM uygulaması geliştirmeye çalışmak,  muhtemelen CRM projesinde çalışanları son derece zorlayacak, CRM projesinin tekrar tekrar ele alınmasını gerektirecektir.

Yazılımların servisler haline dönüşmesi  bir kerede olacak bir iş değildir; küçük ve dikkatli adımlar ile ilerlemek gerekmektedir. Bu dönüşüm esnasında, yeni servisler idealize edilmiş hedef duruma mümkün mertebe yakın hazırlanmalıdır. 
Başlangıçta küçük ama etkili gerçekleştirimler seçerek, sistemlerinizi servisleriniz için seçeceğiniz protokoller ile uyumlulaştırarak başlamak hazırlanacak servislerden maksimum fayda görülmesini sağlıyacaktır. Mevcut sistemlerinizin ideal servislere adaptasyonu, muhtemelen sıfırdan yazılacak servislere göre  servis sayısını daha hızlı bir şekilde arttıracak ve SOA’den edinilecek faydaların da daha hızlı görünür olmasını sağlayacaktır.

Mevcut sistemlerin SOA dönüşümlerinde en sık yapılan hatalardan biri, mevcut sistemlerin ideal servislere adapte edilmeden, birebir servislere dönüştürülmesidir. İdeal durumuna ulaşmaya çalışan bir sistem üzerinde,  servisler arabirimleri ile birlikte değişeceğinden,  SOA’den bir fayda beklenemez. Aksine böyle bir yaklaşımla, SOA geleneksel yazılım geliştirme yöntemlerinden çok daha külfetli bir hale gelecektir. SOA analiz ve tasarım çalışmalarınızda biraz daha özenli olmanızı bekler, bu sebeple projelerde bu safhalara ayıracağınız zamanı daha dikkatli planlamalıdır.

Yukarıda saydığımız faktörler SOA’nin değerini hızlı bir şekilde göstermesi için zorluklar yaratsa da tüm şirketteki tarafların farkındalıkları sürekli bilgilendirme ile arttırılarak SOA programları için gerekli destek sağlanabilir. SOA yolculuğu yokuş çıkan bir kamyona benzetilebilir. Zor zamanlardan sonra yolculuk çok hızlı gitmeye başlıyacaktır.

Sonuç

               Yeni nesil kurumsal mimarilerin başını çeken SOA ve beraberinde BPM, EDA gibi mimari stillerin çok daha yoğun bir şekilde uygulandığını görmeye başlayacağız. Bu yeni yaklaşımlar şirket içerisinde IT’nin yerini  oldukça etkilemekle birlikte, IT’nin iş geliştirme yöntemleri üzerinde de oldukça dramatik etkilere yol açacaktır ve açmaya başlamıştır.
Özellikle ülkemizde, servis odaklılık, popülerlik toz bulutu altında çok da fazla anlaşılamamış olsa da, giderek artan bir şekilde ve evrimleşerek hayatlarımızı etkilemeye, köklü değişimler yaratmaya devam edecektir. Servis odaklı dönüşümlerini tamamlayan şirketler, gelenekçi şirketlere göre çok daha hızlı hareket etme kabiliyetine kavuşacaklarından, gelecekteki market liderlerinin servis odaklı şirketler olacağını öngörmek yanlış olmayacaktır.
               Başarılı bir dönüşüm yolculuğu dileklerimle.

2 yorum:

  1. Serhat bey, bu makale ile, bilişim profesyonellerine yön gösterdiğiniz için teşekkür ederim. Oldukça detaylı anlaşılır ve emek harcanmış bir çalışma gerçekten...

    YanıtlaSil
  2. Elinize sağlık Serhat Bey.
    Rica etsem SOA, BPM ve BPR (Business Process Reengineering) in bir arada olduğu 3 örnek verebilir misiniz? Barkod sistemi gibi.
    Teşekkür ederim.

    YanıtlaSil