Çalıştığım her finansal hizmet organizasyonunun bir entegrasyon sorunu var. Küçük değil. Yıllar içinde biriken, sürdürmesi giderek daha pahalı ve değiştirmesi giderek daha zor olan yapısal bir sorun.
Sorun öngörülebilir: on yıllar içinde satın alınan, inşa edilen ya da miras alınan sistemler, her biri kendi veri modeliyle, her biri diğerleriyle noktadan noktaya bağlantılar, zamanlanmış toplu işler, dosya transferleri ve manuel uzlaştırmalardan oluşan koleksiyon aracılığıyla arayüz kuruyor. Bu bağlantıların toplamı bir mimari değil. Tasarım olmadan ortaya çıkmış bir topoloji.
Entegrasyon Neden Erteleniyor
Entegrasyon borcunun birikmesinin nedeni yapısal: düzeltmek pahalı, görünmez ve görünür iş değeri sunmuyor.
Bir organizasyon müşteriye yönelik yeni bir özellik inşa ettiğinde, değer anında görünür. Poliçe yönetim sistemi ile aktüeryal veri ambarı arasındaki altta yatan entegrasyonu düzelttiğinde, değer savunmaya yönelik — uzlaştırma yükünü azaltıyor, veri kalitesini iyileştiriyor, gelecekteki değişiklikleri ucuzlatıyor. Bunların hiçbiri hiçbir dashboard'da görünmüyor.
Defalarca yaşandığını gördüğüm örüntü: yeni bir düzenleyici gereksinim geliyor. Uyuma en hızlı yol, kaynak sistemden raporlama pipeline'ına noktadan noktaya bağlantı. Bağlantı inşa ediliyor. Deadline karşılanıyor. Entegrasyon borcu artıyor. Bir sonraki düzenleyici gereksinim geldiğinde aynı yol izleniyor. Zamanla raporlama altyapısının on beş farklı kaynak sisteme doğrudan bağımlılıkları var, her biri değiştiğinde barındırılması gerekiyor.
Bu, ödenmemiş borç üzerindeki bileşik faizin teknik karşılığı.
İyi Entegrasyon Altyapısı Nasıl Görünür
Somut olmak istiyorum, çünkü bu soyut prensiplerin pek yardımcı olmadığı bir alan.
Kanonik entegrasyon katmanı. Sistemler arasındaki noktadan noktaya bağlantılar yerine, farklı sistemlerin iç temsilleri arasında çeviri yapan merkezi entegrasyon katmanı. Bir kaynak sistem değiştiğinde, entegrasyon katmanı bir kez güncelleniyor. Aşağı akış tüketicilerin bunu bilmesi gerekmiyor. Bunu Anadolu Hayat Emeklilik'te BizTalk Server kullanarak inşa ettim — doğrudan sistem bağlantıları koleksiyonunu tek bir yönetilen katmanla değiştiren merkezi ödeme entegrasyonu. Operasyonel fayda anında oldu: bir sistemdeki değişiklikler artık ona bağlı tüm sistemlerde değişiklik gerektirmiyordu.
Önemli olduğu yerde olay güdümlü, olmadığı yerde toplu. Her şeyin gerçek zamanlı olması gerekmiyor. Türkiye'deki düzenleyici raporlama tanımlı gönderim döngülerinde işliyor. Verinin doğru olması için gerçek zamanlı akması gerekmiyor. Ama toplu işlemin her zaman kabul edilebilir olduğu varsayımı, verinin önemli şekillerde eski olduğu mimarilere yol açıyor — müşterinin son işlemi risk modelinde görünmüyor, ödeme dünkü poliçe verisiyle işleniyor. Entegrasyon mimarisi, sistemlerin nasıl iletişim kurduğuna dair varsayılan bir kabul değil, her veri akışının gerçek gecikme gereksinimlerini yansıtmalı.
Sistemler arasında açık sözleşmeler. A Sistemi B Sistemine veri gönderdiğinde, şema, anlambilim ve doğrulama kuralları belgelenmiş ve uygulanıyor olmalı. A Sistemi değiştiğinde, sözleşme güncelleniyor, her iki taraf onu gözden geçiriyor ve değişiklik bilinçli olarak yönetiliyor. Çoğu eski entegrasyon ortamında sözleşmeler örtük — belgeleme olmaksızın her iki sistemde de kodlanmış. Biri değiştiğinde, diğeri hemen belirgin olmayan şekillerde bozuluyor.
Yetenek Boyutu
Entegrasyon çalışması giderek nadir olan belirli bir beceri seti gerektiriyor: eski kurumsal sistemlerin veri modellerini derin anlama, aralarında çeviri yapabilme ve gözlemlenebilir, hata ayıklanabilir ve bakımı yapılabilir entegrasyon inşa etme operasyonel içgüdüsü.
Yeşil alan geliştirmeye çekilen mühendisler entegrasyonu gösterişsiz buluyor. Başkasının veri modeliyle, başkasının kısıtları içinde çalışmak, görünür kullanıcıya yönelik çıktı üretmemek. Ama karmaşık eski ortamları olan finansal hizmet organizasyonlarında, mevcut en yüksek kaldıraçlı çalışmalardan — çünkü her aşağı akış veri ürününün kalitesi onu besleyen entegrasyonun kalitesine bağlı.
Düzenlenmiş ortamlarda veri rolleri için işe alırken, bu çalışmayı yapmış ve bundan özür dilemeyen insanları özellikle arıyorum. Yalnızca yeni sistemler inşa eden mühendislerin sahip olmadığı bir şekilde sorun alanını anlıyorlar.
Yatırım Gerekçesi
Entegrasyon yatırım gerekçesini dahili olarak ortaya koymak, zaten açıklanan nedenlerle zor: değer savunmaya yönelik ve görünmez. İşe yarayan yaklaşım, mevcut maliyeti görünür kılmak.
Ekip, anlaşması gereken ama anlaşmayan sistemler arasında veriyi uzlaştırmak için haftada kaç saat harcıyor? Kaç üretim olayı bir entegrasyon hatasına kadar izlenebilir? Entegrasyon merkezileştirilmediği için bir düzenleyici değişiklik kaç kez birden fazla sistemde güncelleme gerektirdi?
Bu maliyetler sayıya döküldüğünde — kabaca bile olsa — entegrasyon altyapısına yatırım farklı görünüyor. Uzlaştırma yükünü azaltan, değişim yönetimini merkezileştiren ve sistemi gözlemlenebilir kılan mimari, yalnızca teknik düzgünlük değil, operasyonel kapasiteye yatırım.
Entegrasyon, kimsenin sahiplenmek istemediği ve herkesin bağlı olduğu veri mimarisinin parçası. Buna bilinçli olarak yatırım yapan organizasyonlar — kolaylık yoluyla birikmesine izin vermek yerine — yangın söndürmek için daha az, önemli işler için daha fazla zaman harcıyor.