ArchiMate - Episode II

Bir önceki ArchiMate yazımda yeteri kadar kafa karıştıramadığımı düşünüp ArchiMate yazıma devam etme kararı aldım. Henüz kurtulamadınız yani…

Modellemedeki nesneleri tek başına tanımlamak yetmeyecektir. Sadece envanter takibi yapmayacağımıza göre, bunların arasındaki etkileşimler de önemli. ArchiMate’in ikinci önemli yapıtaşı: İlişkiler. Kullanılabilecek ilişki türleri, UML gibi diğer standartları temel alarak tanımlamış. Farklı öğeler arasında kurulacak ilişkiler az sonra bahsedeceğim Viewpoint/View konusunda da önemli. Compositon, Realization, Used by/Uses kullanılabilecek ilişki türlerinden bazıları.

Şimdi ilk yazıdaki sorulardan birine dönelim: Farklı paydaşlar için nasıl modeller üretmeliyim? Viewpoint ve View bu amaçla geliştirilmiş ArchiMate kavramları. Belirli bir paydaş grubuna hitap edecek ve onların endişelerini (concern) adresleyecek şekilde özelleştirilmiş mimari modele view diyoruz. View larda kullanılacak öğeler, ilişkiler, analiz ve tekniklere de viewpoint diyoruz. Kısaca, view gördüğüm şey; viewpoint te nereden baktığım. Viewpoint ler, mimariye belirli açılardan bakabilmek ve bunun iletişimini yapmak için tanımlılar. Paydaşlara yapılacak sunumlar/iletişim/paylaşımlarda kullanılacak view içerisinde ne olacağı, nasıl olacağı viewpointlerde tanımlı. ArchiMate içerisinde, olabilecek tüm paydaşları adresleyebilecek bir viewpoint kümesi tanımlı. Örneğin, Organization Viewpoint tamamen kurumun organizasyonel yapısını tanımlayabilecek İş Mimarisi öğelerini ve ilişkilerini içerirken, Infrastructure Usage Viewpoint uygulama ve uygulamayı destekleyen Uygulama ve Teknoloji Mimarisi öğelerini içeren bir viewpoint olarak tanımlanmış. ArchiMate içerisinde toplam 18 adet viewpoint tanımı var.

Mimari katmanlarda kullanılabilecek ArchiMate öğelerini burada detaylı olarak anlatmaya gerek yok. Yazının sonunda direkt ArchiMate spec’ine bir bağlantı var. Oradan öğeleri de içeren tüm spec i detayları ile okuyabilirsiniz. İlk okuyuşta (hatta muhtemelen ikinci ve üçüncü okuyuşlarda da) öğeler, anlamları ve kullanımları birbirine karışacaktır. Ama bu öğeleri eleyip, kendi kullanımınıza göre uyarladığınızda aklınızdaki sorular azalacaktır.

Aşağıda tüm katmanlardan öğeler içerebilecek Layered Viewpoint yapısında bir view var. Model sigorta başvuru ve değerlendirme mimarisini tanımlıyor. Tüm katmanları içerdiği için de hedef paydaş neredeyse kurumun tamamı. Okuması zor farkındayım ama farklı katmanların etkileşimini göstermek için iyi bir örnek olacağını düşündüm.

Benim için ArchiMate’i önemli kılan birkaç noktadan bahsederek devam edelim:

• Standartlarla çalışmak her zaman avantajlıdır. Eğitim, oryantasyon, okuma, araç kullanımı, geliştirme gibi konularda hem maliyeti hem anlaşılırlığı artırır.
• Esnek bir dil. Modellemelerinizde tüm katmanları veya katmanlardaki tüm öğeleri kullanma zorunluluğunuz yok. KM nizde neyi adresliyorsanız, hangi paydaşları sürece katacaksınız, hangi paydaşlar için önemli olan konular (concern) neler?  
• TOGAF kullanıyorsanız, TOGAF ile hizalanmış bir modelleme dili kullanmalısınız. TOGAF , ArchiMate e göre çok daha kapsamlı. O yüzden ilk bakışta ArchiMate tüm TOGAF adımlarını adreslemiyor gibi görünse de, ArchiMate e yapılan 2 ekleme ile tüm ADM desteklenir duruma geliyor: Motivation Extension ve Implementation and Migration Extension.

ArchiMate açık bir standart. Sertifikasyon programı olsa da, sertifikasız da kullanılabilecek bir dil. ArchiMate Specification belgesine bu bağlantıdan ulaşabilirsiniz.

ArchiMate - A New Hope

Kurumsal Mimari (KM) disiplinini oluştururken veya çalıştırırken, aşağıdaki cevaplaması zor sorulardan kaçmak imkansız:

• Modellerimde, KM alanımdaki hangi katmanlardaki, hangi nesneleri kullanacağım?
  TOGAF da kullansanız, başka bir framework de kullansanız, ‘yöneteceğim’ dediğiniz mimari katmanları ve nesneleri sız belirleyeceksiniz. ‘Altyapıya girmeyeceğim, banane!’ diyebilirsiniz.
• Farklı paydaşlar için nasıl modeller üretmeliyim?
  İş birimine gösterdiğiniz sunumu yazılım birimlerine gösterirseniz ‘burada yeterli detay yok’ diyeceklerdir. Yazılım birimine gösterdiğiniz sunumu C-level a gösterirseniz ‘bize anlayacağımız şekilde ve kısa anlat. 10 dakikan var!’ deme olasılıkları yüksek. Bu sebeple KM disiplininin ilgilendirdiği tüm paydaşlar için ilgili nesneler ile uygun bakış açılarında, uygun bir sunum katmanınız olmalı.
• Geliştireceğim modellerde standardı nasıl sağlayacağım? Framework üm belli bir olgunlukta ama ya modellerim?
  Framework dokümantasyonunuz tamamlanmış ve her gelen yeni eleman bu belgeler ile belirli bir noktaya gelebilecek durumda olabilir. Peki modelleri okuma ve yaratma konusunda yeni gelen elemanlarınız veya kurumun diğer çalışanları ne yapacak? En iyisi ortak (ve mümkünse standart) bir dil kullanmak.

Her soruda olduğu gibi, bu soruları ilk soran ilk olmayacaksınız. Hollanda’lı bir ekip bu (ve muhtemelen çok daha fazla soruyu) sormuş ve tüm bu modelleme konuları için ortak/standart/kolay/görsel bir dil oluşturma yoluna gitmişler. Sonuç: ArchiMate. Üniversiteler ve araştırma merkezlerinin iki yıldan fazla bir süre üzerinde çalıştığı ArchiMate’in sahipliği 2008’de The Open Group’a (TOG) devredilmiş. Şu anda TOG’taki diğer forumlar gibi üzerinde çok fazla paydaşın çalıştığı bir standart haline gelmiş.

ArchiMate temelde bir modelleme dili. TOGAF ı temel alarak hazırlanmış, tanımlı bir metamodeli olan, açık kaynak, bağımsız, farklı paydaşlara yönelik görselleştirme, analiz ve tanımlama amaçlı kullanılan, görsel bir modelleme dili. ArchiMate tüm olası durumları ve senaryoları bütün detayı ile kapsayabilecek şekilde tasarlanmamış – basit olmasına özen gösterilmiş. Kendi ifadeleri ile öğrenme ve kullanım kolaylığı adına, pratikte ortaya çıkabilecek ‘ortak’ durumların %80 i için yeterli olabilecek kapsamda bir dil geliştirilmiş.

Dilin yapısına (sadede) gelelim. Dil TOGAF’ta adreslenen üç mimari katmanı adresleyecek yapısal öğeler üzerine kurulmuş. Bu 3 katmanda da, öğeler doğaları gereği kategorize edilmiş: (yazıyı hazırlarken sadece MSPaint kullanabildim :(( )

‘Doğaları gereği’ derken kastım ne? Aslında cümlenin öğeleri gibi düşünebiliriz:

• Active structure: Herhangi bir ‘davranış’ta bulunma yeteneği olan öğelerdir. Cümlemizin öznesi olarak düşünebiliriz. Örneğin iş aktörleri, uygulama bileşenleri veya cihazlar gibi.
• Behavior: Bir veya birden fazla active structure tarafından gerçekleştirilen ‘aktivite’lerdir. Cümlemizin yüklemidir. Örneğin süreçler, servisler, fonksiyonlar gibi.
• Passive structure: Active structurelar tarafından, üzerinde bir aktivite gerçekleştirilen öğelerdir. Yani, cümlemizin nesnesi. Örneğin veri nesneleri gibi.  

ArchiMate metamodelinde iki kavram daha var; kafa karıştıracak iki ArchiMate kavramı daha: Service ve Interface. Service, bir sistemin, iç çalışma detayını gizleyerek, çevresinin kullanımına açtığı ve değer üreten bir işlev seti olarak tanımlanıyor. Bildiğimiz evrensel servis tanımının neredeyse aynısı. Ama bu, Behavior öğelerinde örnek verdiğimiz servisten farklı. Service kavramı tamamen yukarıda tanımlanan öğelerin aralarındaki etkileşimi tanımlamak için kullanılıyor. Interface ise, Service in çevrenin kullanımına açıldığı erişim noktasını ifade ediyor. Özetle: Active structure lar, Interface ler üzerinden eriştiği Service ile, Passive Structure lar üzerinde Behavior lar gerçekleştirir. Bu çok kötü Türkçe-İngilizce cümle sizi yorduysa, aşağıdaki ArchiMate metamodeli daha açıklayıcı olacaktır.

Buraya kadar yeteri kadar karmaşık anlatabildim sanırım :) Yazının ikinci bölümünde işleri biraz daha karıştırmayı düşünüyorum. En kısa zamanda tamamlayıp buradan paylaşacağım...

Kurumsal Mimari Araçları

IT dünyasının içinde olanlara bile Kurumsal Mimarı (KM) kavramını anlatmak, onları bu işin gerekliliğine ikna etmek zorken (hatta gerekliliğinden çok yapılabilirliğine), bu işi iş birimlerine anlatmak ve onları ikna etmek apayrı bir ustalık gerektirir. İşte bu noktada kullanabileceğiniz silahlardan biri de ‘Kurumsal Mimari Araç’ larıdır.

‘Araç’ konusuna sadece satış aşamasında kullanılabilecek bir silah olarak bakmak işi baya hafife almak demek aslında. Hatta işi ‘KM aracı satmak’ olarak görmek de söz konusu, ki bu da odağı KM yönetiminden alıp araç yönetimine odaklar ve KM programını başarısızlığa kadar sürükleyip kurumları bu işten vazgeçirebilir.

Araç konusunu daha da başa sararsak soruyu ‘Araç gerekli mi?’ diye sormak lazım. Araç bir zorunluluk değil. Kurduğunuz/Kullandığınız framework e göre araç ihtiyacı olmayabilir de. Yönettiğiniz artifactler veya deliverable lar, mimari modelleriniz, temel ofis uygulamaları veya açık kaynak modelleme araçlarında yönetilebilir pekâlâ. Fakat KM sadece dokümantasyondan ibaret değil - olmamalı. Bu belgelerin varlığı bir ‘iş’ çıkardığınızı gösterse de asıl sorgulanacak şey çıkardığınız işin katma değer üretip üretmediği olacaktır. Peki, aracın katma değer üretmenize katkı sağlaması için ne ‘yapabiliyor olması’ lazım?

·         Üretilen çıktıların,  modellerin, envanterlerin (portföylerin) tek bir ortamda yönetilmesi ve farklı katmanlarda ilişkilendirilmesi à Etki analizi sağlar.

·         As-is  ve To-be  mimarilerinin (idealde) tek bir tık ile karşılaştırılabilmesi à To-be mimarilere gitmek için yapılması gereken işlerin (projeler, programlar, çalışmalar, vb.) belirlenmesini sağlar.

·         İş/Teknoloji stratejileri, talepler ve projeler  ile mimari ürünlerin ilişkilendirilmesi à İş ile IT arasındaki hizalanmanın izlenebilir olmasını sağlar.

·         Kurumsal mimari prensip ve standartların tutulacağı bir bilgi bankası à Bu bilgilerin kurum içinde bilinir, erişilebilir olmasını sağlar.

·         Kurumsal mimari uyumluluk değerlendirme için bir kayıt havuzu à Kurumda KM uyumluluğunun denetlenmesini kolaylaştırır.

Tabi bunları söylemesi kolay. Araç kullanımından, ya da şöyle diyeyim, tüm mimarinin tek bir araçta yönetilmesi konusundan neden uzak duruluyor? Birkaç farklı sebebi var: Bunlardan birincisi, araç kullanılırsa ortaya çıkacak efor – hem satın alma öncesi hem de sonrası ortaya çıkacak efor. İkincisi işin maliyeti. Bu araçların bir kısmı gerçekten maliyetli. Ayrıca iş satın alma maliyeti ile de bitmiyor. Aracın danışmanlığını da almak zorundasınız. Bakım maliyeti ayrı bir kalem.

Peki, araç kullanmaya karar verdiniz ama hangi aracı seçeceğinize nasıl karar vereceksiniz? Bence araç seçerken en azından aşağıdaki soruları sormakta fayda var:

1.       Aday araç, kullandığım frameworkün kapsadığı mimari katmanların hangilerini destekliyor?
Örneğin altyapı mimarisini ve bağlı modellemeleri, nesneleri desteklemeyen bir aracı tercih etmeyebilirim.

2.       Aday araç, ürettiğim artifact ve deliverable larımı, mimari öğelerimle ilişkilendirmeme ve araç üzerinde takip etmeme izin veriyor mu?

3.       Aday araç, entegrasyon ihtiyacı duyduğum noktalarda bana nasıl imkanlar sağlıyor? Örneğin uygulama portföyümü proje yönetim aracımla paylaşmak isteyebilirim. Veya veri mimarisi katmanındaki öğelerimi fiziksel veri modelleme aracıma göndermek isteyebilirim.

4.       Aday araç, hangi mimari standartları destekliyor? Kurumda Archimate veya TOGAF ın metamodelini kullanmak isteyebilirim. Aday araç bunları için hazır bileşen seti ile mi geliyor yoksa özelleştirme gerekir mi?

5.       Aday araç, mevcut bileşenlerin özelliklerini ihtiyacıma göre genişletme (extendable) imkanı sunuyor mu?

6.       Aday aracın raporlama (görsel sunum veya belge üretme) yetenekleri nelerdir?

7.       Aday araç, çok kullanıcılı bir çalışma ortamına izin veriyor mu?

8.       Aday araç, KM modellemesi dışında bir modelleme imkanı sunuyor mu? Örneğin iş süreçlerimi de BPMN ile modellemek ve süreç detaylarımı iş mimarisi ile ilişkilendirmek isteyebilirim.

Aracı nerede (hangi süreçlerde kimler tarafından) kullanacağınızı netleştirdikten sonra bu soruları daha da artırmak mümkün. İşin içine versiyonlama, yetkilendirme gibi daha teknik detaylar da girecektir.

Gartner 2004’ten beri (muhtemelen daha biz Kurumsal Mimari’nin ne olduğunu bile bilmiyorken ve Kurumsal Mimari’yi diğer mimari disiplinler ile karıştırırken) piyasadaki KM araçları ile ilgili Magic Quadrant yayınlıyor – konuya aşina olmayanlar için, Magic Quadrant piyasada belirli bir Pazar payına ve olgunluğa sahip ürünlerin değerlendirilip karşılaştırıldığı bir analiz. Gartner’ın bu yaklaşımı aslında hem araç konusunun hem de KM yönetiminin önemini bir nebze işaret ediyor diyebiliriz. 

Gartner’ın magic quadrant’ında yer alan araçların bir kısmının Türkiye'de temsilcilikleri var. Fakat hangisi piyasada ne kadar yaygın derseniz biraz kısır bir tablo çıkıyor ortaya. Bu sebeple tercih edeceğiniz aracın (ofis uygulamalarından vazgeçebilirseniz) Türkiye'deki mevcut danışmanlık deneyimi de önem kazanacak. Ayrıca alınacak danışmanlığın KM disiplininize ne kadar katkı sağlayabileceği de ayrı bir soru işareti. Ek olarak Türkiye'de yer alan bazı yabancı menşeli firmalar yurtdışı merkezlerinin kendilerine zorunlu tuttuğu KM araçlarını da kullanıyorlar. Tabi zorunluluk olduğu için bu araçlar ne verimlilikte kullanılıyor bilemiyorum.

Bu arada Gartner’ın çalışmasında yer alan araçların hepsinin güçlü yanları ayrı. Kimisi daha stratejik açıdan yaklaşırken kimisi daha standart temelli gidiyor. Araştırma yaparken deneme sürüşünü yaptığım araçlar BiZZDesign Architect Ve Avolution Abacus oldu. Bu araçlarla ilgili yorumlarımı ayrı bir yazıda toparlamayı düşünüyorum.

Peki, sonuç ne: Araç kullanımı gerekli mi? Bence kesinlikle gerekli. Tek bir şartla; önce KM disiplininizi ve frameworkünüzü tanımlamalı, geliştirmeli ve yerleştirmelisiniz. Hangi katmanda, hangi çıktılarla, hangi süreçlerde, hangi detayda KM yapacaksınız? Araç tek başına hiçbir mimari sorunuza cevap vermeyecektir. İkinci sorumuz da belli; hangi aracı kullanmalı? Bu sorunun tek bir cevabı yok. Piyasada yetkinlikleri birbirinden farklı çok araç var. Siz KM olarak ne yapacağınıza karar verdikten sonra araç seçmek kolaylaşacaktır.

Not: Artifact ve deliverable TOGAF terimleri. Kısaca açıklamak gerekirse

-          Artifact mimarimizi belirli bir bakışa açısından tanımlayan mimari çalışmadır. Diagramlar, katalog ve matrisler şeklinde hazırlanabilir.

-          Deliverable bir proje sürecinde hazırlanan, gözden geçirilen ve tüm paydaşlar tarafından mutabık kalınan çıktıdır. Delvierable lar bir veya birden fazla artifact içerebilir.

*Bu yazı arkadaşım Kurumsal Veri Mimari Ufuk Yüzereroğlu tarafından yazılmıştır.

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