Heterojen Kurumsal Bilgi Sistemleri İçin Birlikte Çalışabilirlik Çözümü: Aydos Sinan Kahveci1, Muhammed Cuma Tahiroğlu2

Heterojen Kurumsal Bilgi Sistemleri İçin Birlikte Çalışabilirlik Çözümü: Aydos

Sinan Kahveci¹, Muhammed Cuma Tahiroğlu<sup>2

1, 2</sup> Türkiye Finans Katılım Bankası, İstanbul

[e-mail], [e-mail]

Özet: Günümüzde kuruluşlar gelişen teknolojiyle birlikte artan iş ihtiyaçları doğrultusunda kullandıkları yazılımları ve yazılım altyapılarını düzenli olarak takviye etmek veya dönüştürmek ihtiyacı duymaktadır. Bu kapsamda yapılan her yeni geliştirme ve satın alma, sağladığı kritik faydaların yanında mevcut sistemin heterojenliğini ve karmaşıklığını biraz daha artırmaktadır. Bu durumun beraberinde getirdiği sorunların başında giderek artan entegrasyon ihtiyacı, erişim, yetkilendirme problemleri ve kullanıcı deneyimi şikayetleri gelmektedir. Söz konusu ciddi olumsuzluklar uygulanacak etkin birlikte çalışabilirlik çözümleriyle azaltılabilmektedir. Bu çalışmada, "Aydos" kod adıyla geliştirilen bir birlikte çalışabilirlik çözümü açıklanmış, sağlanan önemli kazanımlar paylaşılmış ve uygulamaya dair önerilerde bulunulmuştur.
Anahtar Sözcükler: Birlikte Çalışabilirlik, Kurumsal Entegrasyon, Bankacılık, Yazılım.
An Interoperability Solution for Heterogeneous Enterprise Information Systems: Aydos
Abstract: Today, organizations need to transform or reinforce their software and software infrastructures regularly in line with the growing business needs with evolving technology. In this context, each new development and procurement increase the heterogeneity and complexity of the current system slightly besides the provided critical benefits. The most common and important problems posed by this situation are the growing enterprise integration needs, authentication, authorization issues and user experience complaints. Mentioned significant disadvantages can be reduced by implementing effective interoperability solutions. In this paper, an interoperability solution called "Aydos" code name has been described, remarkable gains have been shared and suggestions have been made concerning the implementation.
Keywords: Interoperability, Enterprise Integration, Banking, Software.

1. Giriş
Eğitimden sağlığa, bilimden bürokrasiye, sanayiden finans sektörüne kadar bütün kuruluşlar; bilgi teknolojilerindeki (BT) baş döndürücü değişim ve gelişime ayak uy-durmak için, kullandıkları yazılımları ve yazılım altyapılarını güncel ihtiyaçlarına cevap verecek şekilde takviye etmek veya dönüştürmek ihtiyacı duymaktadır.
Günümüzde bilhassa bankalar; iktisadi büyüme ve küreselleşmeye paralel olarak rekabetin sertleştiği, yasal düzenlemelerdeki değişikliklerin süratle hayata geçirilmesinin gerektiği, kullanılan işlem kanallarının çeşitliliği nedeniyle entegrasyon ihtiyaçlarının her geçen gün biraz daha önemini artırdığı bir ortamda faaliyet göstermektedir. Dolayısıyla gerek müşterilerinin gerekse de müşterilere hizmet sunan çalışanlarının istek ve gereksinimlerini karşılayacak yenilikçi teknolojileri geliştirmek veya satın almak için sürekli çalışma yapmaktadır.
Mevcut yazılım ortamına eklenen her yeni hizmetin öncelikli hedefi, elzem bir ihtiyacı karşılayarak organizasyona önemli katkılar sağlamaktır. Ancak çoğu zaman farklı ihtiyaçların farklı teknolojilerle adreslenmesi gerekliliği sebebiyle, yapılan her yeni geliştirme veya satın alma, sağladığı faydanın yanında mevcut sistemin karmaşıklığını ve heterojenliğini biraz daha artırmaktadır. Bu da her farklı uygulama için, erişilmesi gereken yeni bir adres (yol), aşılması gereken uygu-lamaya özel erişim/yetkilendirme gibi temel altyapılar, birbirinden farklı kullanıcı deneyimlerine (user experience) sahip menü ve arayüzler anlamına gelmektedir. Neticede uç kullanıcılar (client), kompleksliği zamanla daha da artan bu heterojen yazılım dünyası içerisinde ciddi erişim ve kullanım zorlukları yaşayabilmektedir. Bu durumun iş kalitesine, hızına ve son kullanıcı (client) memnuniyetine kayda değer olumsuz etkilerinin olduğu yadsınamaz bir gerçektir. İşte bu gibi olumsuzluklar, bahsi geçen heterojen yazılım ortamını oluşturan uygulamaların birbiriyle etkin bir şekilde konuşabilmesine ve ortak yapılardan mümkün olduğunca fazla istifade edebilmesine imkân tanıyan birlikte çalışabilirlik (interoperability) çalışmalarının yapılmasıyla azaltılabilir.
Bu bildiride, Türkiye Finans Katılım Bankası’ndaki heterojen kurumsal (enterprise) yazılım ortamında başarıyla hayata geçirilmiş bir birlikte çalışabilirlik çözümü tüm yönleriyle açıklanmıştır. Uygulanan etkin birlikte çalışabilirlik modelinde, bu alandaki diğer pek çok çalışmasının aksine, sadece Servis Odaklı Mimari (SOA) ile sağlanan teknik birlikte çalışabilirlikle sınırlı kalınmamış, kullanıcı arayüzü entegrasyonunu (user interface integration) içeren geliştirmelere ağırlık verilmiştir. Böylelikle farklı teknolojik altyapılara sahip hizmetlere, ortak (entegre) bir arayüzden erişebilmenin getirdiği faydalar net bir şekilde deneyimlenmiştir.
Bir sonraki bölümde, büyük bir bilgi sistemini oluşturan örnek heterojen kurumsal yazılım ortamı ve bu ortamın zorlukları hakkında bilgi verilmiştir. Kullanıcı talepleri dikkate alınarak geliştirilen birlikte çalışabilirlik çözümü üçüncü bölümde açıklanmıştır. Son bölümde ise üretilen katma değer özetlenmiş ve sonraki çalışmalara ilişkin önerilere yer verilmiştir.

2. Heterojen Kurumsal Bilgi Sistemi
Kurumsal yazılım (enterprise application software - EAS), kurumsal çaptaki karmaşık problemlerin çözümünde organizasyona yardımcı olmak için kullanılan uygulamaları tanımlayan bir terimdir [1]. Kurumsal yazılımların temel amacı, organizasyonun iş hedeflerini karşılayacak, üretkenliğini ve verimliliğini artıracak fonksiyonelliği sağlayabilmektir. Dolayısıyla bir kurumsal bilgi sistemi; muhasebeden müşteri ilişkileri yöne-timine (CRM), kurumsal kaynak planlamasın-dan (ERP) iş zekâsına (BI), insan kaynakları yönetiminden BT hizmet yönetimine ve doğal olarak bütün bu platformlar üzerinde uygulama (yazılım) geliştirmek için kullanılan araçlara ve altyapılara kadar pek çok farklı hizmeti içerecek çeşitlilikte olabilir. İster kurum içi (in-house) geliştirilsin isterse de tedarikçiler-den satın alınsın, sunulan bütün bu hizmetlerin sahip oldukları yazılım altyapıları ve mimarilerindeki farklılıklar ise kurumsal bilgi siste-minin heterojenliğini belirler.

Bankaların kurumsal bilgi sisteminin büyük bölümünü, bilişim yatırımlarından en fazla payı alan, müşteri, hesap, işlem vb. tüm finans bilgilerinin tutulduğu ve uçtan uca işletildiği ana bankacılık sistemleri ve uygulamaları oluşturmaktadır. Türkiye Finans’ta, Bilgi Yönetim Sistemi (BYS) olarak adlandırılan bu ana yazılım sistemindeki bankacılık ekranları iki ayrı mimaride geliştirilmiştir.

Mimari	Dil	Legacy	Oran
İstemci-sunucu	VB6	Evet	% 11
İstemci-sunucu	C#	Evet	% 9
SOA	C#	Hayır	% 80

Tablo 1. Örnek ana bankacılık sisteminin heterojen yazılım altyapısı
İstemci-sunucu mimarisinde inşa edilen, eski (legacy software) [2] olarak nitelendirebileceğimiz sistem, uzun soluklu bir ana bankacılık dönüşüm projesiyle, kurumun iş hedefleri doğrultusunda büyük oranda SOA [3] mimari-sine dönüştürülmüştür. Bununla birlikte iki farklı yazılım diliyle geliştirilmiş olan ve halen aktif bir şekilde kullanılan eski (legacy) mimari bankacılık ekranlarının ana bankacılık siste-minin tamamına oranı %20’yi bulmaktadır.
Bankalar ayrıca, organizasyonun büyüklüğü, karmaşıklığı ve süreçlerinin çeşitliliği gereği, ana bankacılık sistemi dışında kabul edebileceğimiz iş süreçlerini adresleyen uygulamalar kullanmak ve bu durumun olası zorluklarıyla mücadele etmek durumundadır. Türkiye Finans da birçok iş süreci için farklı teknolojik altyapılarda geliştirilmiş yazılımlara sahiptir. Netice itibarıyla karşımıza, gerek ana bankacılık yazılımının kendi içerisindeki teknolojik dönüşümü gerekse de diğer hizmet kanalları için kullanılan uygulamaların çeşitliliğinden ötürü önemli ölçüde heterojen bir bilgi sistemi çıkmaktadır.
Türkiye Finans bünyesinde, son kullanıcı görüşmeleri, uzman değerlendirmeleri, saha çalışmaları, hizmet masasına gelen istek ve şikâyetler gibi çeşitli yöntemlerle sürekli olarak kullanıcı geri bildirimleri toplanmaktadır. Bu geri bildirimler değerlendirildiğinde yukarıda açıklanan kurumsal bilgi sisteminin heterojen yapısından kaynaklanan temel zorlukların aşağıdaki başlıklar altında gruplandığı görülmüştür:

• 
  Entegrasyon: Uygulamaların ortak hizmetlere ve birbirlerine olan entegrasyon ihtiyaçları
  
• 
  Erişim/Yetkilendirme: Her uygulama için farklılık gösterebilen kullanıcı kimlik doğrulama (authentication) ve yetkilendirme (authorization) altyapıları ile uygulamaların sahip olduğu farklı yollar (path) nedeniyle ortaya çıkabilen erişim sorunları
  
• 
  Kullanıcı Deneyimi: Uygulamadan uygu-lamaya farklılaşabilen menü ve arayüz kaynaklı kullanıcı deneyimi karmaşası
  

Neticede söz konusu bu zorlukları en aza indirgemek için etkin bir birlikte çalışabilirlik modeli geliştirilmiş ve başarıyla uygulanmıştır.

3. Birlikte Çalışabilirlik Çözümü: Aydos
En genel manada birlikte çalışabilirlik (interoperability), iki sistemin birbirini anlaması ve birbirinin fonksiyonelliğini kullanabilmesi kabiliyetidir. Bilgi teknolojileri açısından bakıldığında, iki farklı bilgi sisteminin birlikte çalışabilmesi ve birbirlerinin kaynaklarına (hizmetlerine) karşılıklı olarak erişebilmesidir [4]. ISO/IEC 2382-01’e göre ise, kullanıcının farklı fonksiyonel birimler arasında, minimum bilgiyle veya hiç bilgi sahibi olmadan iletişim kurabilmesi, uygulama çalıştırabilmesi veya veri transferi yapabilmesi yeteneğidir [5].
Yukarıda görüldüğü üzere birden fazla tanımı bulunan birlikte çalışabilirlik, kurumsal heterojen bir bilgi sisteminde değişik seviyelerde (enterprise levels) ve farklı yaklaşımlarla hayata geçirilebilir [6]. Türkiye Finans’ta, "Aydos" kod adıyla gerçekleştirilen çalışma, farklı alt-yapılara sahip uygulamaların tek bir yazılım üzerinde koşabilmesini ve birbirleriyle proses (process) seviyesinde etkin bir şekilde haberleşebilmesini kapsamaktadır. Hâlihazırda aktif olarak kullanılan SOA [7] yaklaşımı ve COMWrapper [8] teknolojisi tabanlı başarılı birlikte çalışabilirlik uygulamaları bu makalenin kapsamının dışındadır.
Aydos platformunun iki ana yapıtaşı vardır:

1. 
   Ortak (Paylaşılan) Metaveri
   
2. 
   Kabuk
   

Şekil 1. Heterojen Bilgi Sistemi ve Aydos platformunun genel yapısı
3.1. Ortak (Paylaşılan) Metaveri

Metaveri, bir bilgi kaynağını tanımlayan, açıklayan, konumlandıran veya diğer bir ifadeyle erişimini ve kullanımını kolaylaştıran veya yöneten yapısal bilgidir. Genellikle veri hakkında veri veya bilgi hakkında bilgi olarak da tanımlanır [9].

Aydos platformunda metaveri, heterojen kurumsal bilgi sistemini oluşturan uygulamaların, uygulamalara ait ekranların, hatta ekranların içerisindeki alanların hakkında bilgi içerebilecek ayrıntıda tasarlanmıştır. Böylelikle yazılım ekosistemini oluşturan tüm parçacıklar hakkında gereken bilgilerin tek ve güvenilir bir kaynakta saklanması, sunulan servisler aracılığıyla ihtiyaç duyulduğunda kaynaktan alınması ve yardımcı yazılım ekranlarıyla beslenmesi ve yönetilmesi sağlan-maktadır. Metaveri ve onun etkili bir şekilde saklanmasını, kullanılmasını ve yönetilmesini sağlayan altyapı Metaveri Yönetim Sistemi olarak da adlandırılmaktadır.



Şekil 2. Metaveri Yönetim Sistemi’nin Bileşenleri
Yukarıdaki şekilde ifade edildiği üzere Metaveri Yönetim Sistemi üç ana bölümden oluşmaktadır. Bunlardan ilki ilişkisel veri tabanı yönetim sistemi üzerinde oluşturulmuş tablolarda saklanan metaverinin kendisidir. İkincisi metaveriye istenildiğinde rahat ve güvenilir bir şekilde erişilebilmesini sağlayan servislerdir. Sonuncusu ise oldukça detaylı ve kompleks bilgi içeren bu ilişkisel veri modeline kayıt girmek, güncellemek veya mevcut kayıtları yönetmek için kullanılan yardımcı uygulama ekranlarıdır.
Bu ilişkisel veri modelinde, heterojen bilgi sistemini oluşturan her uygulama bir modül olarak ele alınmış ve “Module” tablosuna uygulamaya özel bilgileri girilmiştir. Benzer şekilde uygulamaya ait ekranlar da “Screen” adlı tabloya tek tek tanımlanmıştır. “Module” ve “Screen” tablolarındaki kayıtlar bire çok (one to many) ilişkisine sahiptir. Modüllere veya ekranlara ait yetkilendirme, sınıflandırma gibi kritik öneme sahip bütün bilgiler ilişkisel bir şekilde kendilerine ait tablolarda saklanmaktadır. Metaveri ayrıca heterojen yazılım ortamını oluşturan bu parçacıkların tek bir menü ağacında hiyerarşik olarak sunumu için gereken menü tanım bilgilerini çoklu dil desteği ile birlikte sağlamaktadır.
Modül, ekran, yetki gibi metaveri üzerinde kayıtlı olan her varlık benzersiz bir kimliğe (unique id) sahiptir. Bu benzersiz kimlik bilgileri kullanılarak, Metaveri Yönetim Sis-temi tarafından sunulan servisler aracılığıyla, sisteme tanımlı bir varlık hakkında istenilen detayda bilgiye rahatlıkla ulaşılabilir. Bir sonraki bölümde detayları verilen “Kabuk”, pek çok operasyonunu bu yöntemle elde ettiği verileri yorumlayarak gerçekleştirmektedir.
Heterojen yazılım ortamını oluşturan bir parçacığın yaşam süresi boyunca, o parçacığa ait metaverinin güncel olması gereklidir. İçeri-sinde bu denli ayrıntılı veriyi saklayan bir ilişkisel veri modeli ise, beraberinde getirdiği komplekslik nedeniyle ister istemez bu gerek-sinimin karşılanmasını zorlaştırmaktadır. Veri girişi, güncellemesi ve yönetiminde önemli sorunlara yol açabilecek bu durum, hazırlanan yardımcı yazılım ekranlarıyla giderilmiştir.
Doğru şekilde modellenmiş ortak (paylaşılan) metaveri, heterojen bilgi sistemlerinde birlikte çalışabilirliğin uygulanabilmesi için kritik öneme sahiptir. Birlikte çalışabilirlik, büyük oranda standartlaşmış uygulama programlama arayüzleri aracılığıyla (APIs) gerçekleştirilse de, sistemle ilgili gereken tüm bilginin tutulduğu ortak metaveriye ihtiyaç duyar.

3.2. Kabuk (Shell)

Kabuk, metaveriden web servisleri yardımıyla alınan bilgilerin yorumlandığı, heterojen orta-mı oluşturan parçacıkların sorunsuz bir şekilde çalıştırıldığı ve bu parçacıklar arası iletişimin sağlandığı katmandır.

Bu katmanda, birbirinden farklı teknolojik platformlarda geliştirilmiş, her biri kendine ve adreslediği iş uzayına özgü kullanıcı arayüzü sunan proseslerin arayüz düzeyinde haberleşebilmesi için özel bir mesajlaşma altyapısı kurgulanmıştır.
Mesajlaşma altyapısı kurgulanırken ilk önce mevcut imkânlar ele alınmıştır. İşletim sistemi temel bağımlılık noktası olarak sabit tutul-maktadır. Windows işletim sisteminde bir prosesin diğer proseslerle haberleşebilmesi için başlıca şu seçenekler bulunmaktadır:

• 
  IPC (Interprocess communication) - pipe
  
• 
  TCP/IP (soketler)
  
• 
  Win32 mesajlaşma
  
• 
  Memory mapped file
  

Bunların hemen hepsi her platform tarafından desteklenmektedir. Ancak bu durum, araların-da bazı teknik farklılıklar olmadığı anlamına gelmez. Örneğin Visual Basic 6 platformunda aracısız bir şekilde IPC tekniğini kullanmanın yolu yoktur.

Bu yöntemler arasında Win32 mesajlaşma yöntemi en hızlı cevap vereni fakat uygulaması da en kompleks olanıdır. Her platforma özel kodlama yapma gereksinimi, mesajlaşma altyapısının karmaşıklığını artıracaktır.
TCP/IP yöntemi soket seviyesinde kullanıldığında başarılı ve performanslı sonuçlar vermektedir. Ama Win32’deki her platforma özel kodlama yapma gereksinimi burada da söz konusudur. Çözümümüz kolay uygulanabilir, hata ayıklama (debug) yapılabilir ve rahat anlaşılır bir yöntem olmalıdır.
Analizimiz neticesinde, .NET üzerinden en hafif (lightweight) servis sunma teknolojisi olan Web API [10], uygulamaları entegre etmek için öncelikli seçenek olmuştur. Her platformun .NET’i doğrudan kullanamaması sorunu da kararlı bir teknoloji olan COM (Component Object Model) [11] ile aşılmıştır. COM VB6, Delphi, Java dâhil Windows ortamında çalışan tüm framework’ler tarafından desteklenmektedir. Windows’un ortak bileşen kullanma altyapısıdır ve .NET’ten önceki en gelişmiş uygulama kapsülüdür.
Mesajlaşma için HTTP protokolünün seçilmesi, izlenebilirlik ve hata ayıklama açısından önemli bir kazanım olmuştur. Çünkü herhangi iki proses arasındaki mesajlar, bir web hata ayıklayıcı yazılımı (Charles ya da Fiddler) ile canlı olarak görüntülenebilmektedir. Bu da programcının herhangi bir sorunu daha erken keşfedebilmesine yardımcı olmakta ve beklenmedik sistemsel davranışlarda derinlikli yorum yapabilmesine imkân tanımaktadır.
Altyapının kodlaması bir .NET sınıf kütüphanesi içerisinde gerçekleştirilmiştir. Derlenen DLL (Dynamic Link Library) COMVisible özelliğiyle etiketlenerek işletim sistemi COM kataloğuna kaydedilebilir duruma getirilmiştir. Bir platform üzerinde .NET referansı kullanılamıyorsa COM arayüzü kullanılarak aynı bileşene ulaşılabilmektedir.
Kabuk üzerinden sunulan programlama arayüzünün (API) üç ana metodu vardır:

• 
  StartListening (instanceIdentifier)
  
• 
  SendMessage (target, messageDictionary)
  
• 
  ReceiveMessage(source, messageDictionary)
  

Şekil 3. X uygulamasından Y uygulamasına mesaj gönderimi
StartListening metodunun başarılı işletimiyle arka planda bir web servisinin sunumu başla-tılır ve böylelikle proses, mesaj kabul edebilir duruma gelir. Metoda parametre olarak ge-çilen instanceIdentifier değeri ilgili servisin adres bilgisidir. Kabuk, adresin çalışma zamanında (run time) oluşturulması, saklanması ve ilgili prosesle eşleştirilmesinden sorumludur. Adresin içerisindeki HTTP port konfigürasyonu uygulama yapılandırma dosyasından (app.config) ayarlanabilmektedir.
SendMessage metodu başka bir prosesin üzerinde sunulan ve çağrıları dinleyen servise mesaj göndermeyi sağlar. Hedef prosesin hangi kimlik (ID) ile yaşadığını bilmek, kaynak prosesin sorumluluğundadır. Kabuk’a iletilen mesaj, ID bilgisine karşılık gelen (hedef prosesi tanımlayan) verilerin metaveri yönetim sisteminden alınmasıyla birlikte yeniden yorumlanmakta ve neticede hedef prosesle eşleştirilerek uygun formatta iletilmektedir. Mesaj gönderim metodu hızlı dönüş yapmakta olup ve gönderim operasyonunu arka plan görevi olarak işletmektedir. Bu nedenle ana iş parçacığını (thread) bekleten (blocker) bir metot değildir.
Bir prosese başka bir prosesten mesaj gönderildiğinde ReceiveMessage metodu otomatik çalışmaktadır. Alınan mesajın yorumlanması hedef prosesin sorumluluğundadır. Gönderen prosesin kimliği gerektiğinde yanıt dönebilmek için mesajla birlikte sistem tarafından otomatik olarak gönderilmektedir.
Sağlıklı bir birlikte çalışabilirlik modeli kurgulayabilmek için iyi tanımlanmış standartlar oluşturmak son derece önemlidir [12]. Bu nedenle proseslerin birbirleriyle en çok yapa-bilecekleri alışveriş türleri, belirli düzeyde standartlaştırılmış ve ortak mesaj formatları dokümante edilmiştir. Yani bir proses, başka bir prosesin üzerinde çalışan ekranın açılışını tanımlı mesaj formatlarını kullanarak talep edebilmektedir. Kısacası, her iki prosesin iletişimde kullanılan mesaj formatı konusunda karşılıklı mutabakatının olması ve alınan mesajları yorumlayacak rutinin de hedef prosesde gerçekleştirilmesi gerekmektedir.
Örneğin standart operasyonel ekran açma mesajı “OpenScreen” adıyla kurallaştırılmıştır. Parametre olarak da ekranın ayırt edici kimliği istenmektedir. Bu tür tanımlayıcı bilgiler, Kabuk tarafından metaveri yönetim sisteminden alınmaktadır. Buna göre bir prosesin Bankacılık prosesine gönderdiği bir mesaj şöyle gösterilebilir:
SendMessage (target, [“Action”:“OpenScreen”, “Screen”:”ViewSlip”, “TransactinId”:”1122])
Bu mesaj Bankacılık prosesinde yorumlanıp, ViewSlip ekranı, verilen TransactionId para-metresiyle açılacaktır.
4. Sonuç ve Öneriler

Bu makalede, gelişen teknolojiyle birlikte artan iş ihtiyaçları doğrultusunda giderek daha fazla heterojen hale gelen kurumsal bilgi sistemlerinde karşılaşılan temel zorluklar üze-rinde durulmuş ve bunların aşılmasına yardımcı olmak amacıyla geliştirilen bir birlikte çalışabilirlik çözümü açıklanmıştır.

Geliştirilen birlikte çalışabilirlik çözümü, ilk önce pilot olarak büyük bir organizasyonda yazılım ekiplerinin kullanımına sunulmuştur. DevSuite adıyla Aydos platformu üzerine inşa edilen uygulama, bir yazılım geliştiricinin uygulama geliştirme yaşam döngüsü içerisinde ihtiyaç duyduğu bütün araçları tek bir çatı altında erişilebilir ve etkileşebilir kılmıştır. Yaklaşık bir yıllık pilot uygulamanın aka-binde, alınan son derece olumlu geri bildirimler neticesinde, çözümün benzer şekilde ana bankacılık sisteminin dönüşümü kapsamında yürütülen projede uygulanmasına karar verilmiştir.

Ana bankacılık sistemi için hazırlanan prototiple, sistemin heterojen parçacıkları arasındaki entegrasyon, erişim/yetkilendirme başlıkları altında gruplanabilecek ihtiyaçların karşılanması ve kullanıcı deneyiminin geliştirilmesi adına gerçekleştirilen yenilikler iş birimlerinin beğenisine sunulmuştur.

Farklı uygulamaların tek bir ana uygulama ve menü ağacı üzerinden erişilebilir kılınması; akıllı arama, kişiye özel menü ve müşteri bağ-lamı gibi sık kullanılan pek çok fonksiyonun sistemin bütün heterojen parçacıkları için ortak hale getirilmesine imkân tanımıştır. Ek olarak bu parçacıkların birbirleriyle etkin bir şekilde haberleşebilmeleri, ihtiyaç duyduklarında bir-birlerinin hizmetlerini kullanabilmeleri gibi yenilikler çalışmanın yaygınlaştırılması kararının alınmasını sağlamıştır.

Birlikte çalışabilirlik uygulamalarında dikkat edilmesi gereken hususlar ve tasarım önerileri-ne önceki bölümler içerisinde yer verilmiştir. Fakat son olarak önemli bir konunun altını çizmekte fayda vardır. Başarılı bir birlikte çalışabilirlik çözümünde hedef, iş mantığı entegrasyonundan ziyade farklı platformdaki uygulamalar arasında köprü inşa etmek olmalıdır. Yani birlikte çalışabilirlik katmanına bir iş mantığı, bir bağımlılık yüklenmemeli, bu katmanın çalışmadığı bir durumda kullanıcı, entegrasyona bahis olan prosesleri kullanarak iş çözümünü gerçekleştirebilmelidir. Birlikte çalışabilirlik çözümüyle gelen entegrasyon yeteneğinin sisteme eklediği veya yokluğunda eksilttiği bir iş mantığı kesinlikle olmamalıdır.

5. Kaynaklar

[1] What is enterprise application? - A Word Definition From the Webopedia Computer Dictionary. Webopedia.com.

[2] H. M. Sneed, “Integrating legacy software into a service oriented architecture,” in Conference on Software Maintenance and Reengineering (CSMR’06), pp. 11-14, 2006.

[3] T. Erl, “Service-Oriented Architecture (SOA): Concepts, Technology, and Design”, Prentice Hall, Indiana, 2009.

[4] D. Chen, G. Doumeingts, and F. Vernadat, “Architectures for enterprise integration and interoperability: Past, present and future”, Comput. Ind., vol. 59, no. 7, pp. 647-659, 2008.

[5] ISO/IEC 2382-01, “Information Tech-nology Vocabulary, Fundamental Terms”, [accessed 6 November 2014].

[6] D. Chen, "Enterprise Interoperability Framework", In Proceedings of Enterprise Modelling and Ontologies for Interoperability, EMOI - Interop 2006, CEUR Vol. 200, 2006.

[7] R. M. Pessoa, E. Silva, M. Van Sinderen, D. A. C. Quartel, and L. F. Pires, “Enterprise Interoperability with SOA: a Survey of Service Composition Approaches,” 2008 12th Enterp. Distrib. Object Comput. Conf. Work., pp. 238-251, Sep. 2008.

[8] S. Kahveci and M. C. Tahiroğlu, “Banka-cılık Yazılım Mimari Dönüşüm Projelerinde Geriye Dönük Uyumluluğun Önemi,” TBD 30th National Informatics Congress, pp. 26-30, Nov. 2013.
[9] NISO (National Information Standards Organization), “Understanding Metadata”, NISO Press, Available: , 2004.
[10] G. Block, P. Cibraro, P. Felix, H. Dierking, D. Miller, “Designing Evolvable Web APIs with ASP.NET”, O’Reilly, Apr. 2014.
[11] A. Gordon, “The .NET and COM Interoperability Handbook”, Prentice Hall, Dec. 2002.

[12] J. D. Poole, “Model-Driven Architecture: Vision, Standards and Emerging Tech-nologies”, Workshop on Metamodeling and Adaptive Object Models, ECOOP 2001, pp. 1–15, April 2001.