Kurumsal Yazılımda Entegrasyon Tasarımı Neden Kritik?

Ay sonu toplantısında finans ekibi dört yüz on iki sipariş olduğunu söylüyor. Depo sistemi dört yüz dokuz gösteriyor. Aradaki üç siparişin hangi tarafta yanlış olduğunu kimse söyleyemiyor.

Toplantının geri kalanı rakamların doğrulanmasıyla geçiyor ve asıl konu bir sonraki haftaya kalıyor. Bu, teknik bir aksaklık gibi görünür; oysa kaybedilen şey veri değildir. Kaybedilen şey, sayılara güvenerek karar verebilme imkânıdır.

Entegrasyon tasarımının kurumsal yazılımda bu kadar belirleyici olmasının nedeni budur: iki sistem birbirine bağlandığında ortaya çıkan asıl risk, verinin taşınamaması değil, iki tarafın farklı bir doğruyu bilmesidir.

Entegrasyon, veri taşımak değil anlam üzerinde anlaşmaktır

Entegrasyon projeleri genellikle bir taşıma işi olarak konuşulur: şu alanı alalım, şu alana yazalım. Teknik kısım gerçekten de budur ve genellikle en kolay kısımdır.

Zor olan kısım, aynı kelimenin iki sistemde aynı şeyi ifade etmemesidir.

Satış sistemindeki "müşteri" bir kişidir; muhasebe sistemindeki "müşteri" bir fatura adresidir. Aynı şirketin üç şubesi biri için tek bir kayıt, diğeri için üç ayrı kayıttır. "Sipariş kapandı" bir tarafta ürün gönderildiğinde, diğer tarafta ödeme tahsil edildiğinde gerçekleşir — arada geçen üç gün boyunca iki sistem de kendi tanımına göre doğrudur.

Bu farklar entegrasyon sırasında keşfedilmez; entegrasyon canlıya alındıktan aylar sonra, tutmayan bir raporla keşfedilir. Bu yüzden bir entegrasyonun ilk adımı bağlantı kurmak değil, iki tarafın sözlüğünü karşılaştırmaktır: hangi kavram nerede nasıl tanımlanmış ve nerede ayrışıyor?

Anlaşmazlık istisna değil, sistemin normal hâlidir

Entegrasyonlar çoğunlukla iki sistemin sürekli aynı bilgiyi bileceği varsayımıyla tasarlanır. Bu varsayım pratikte hiçbir zaman tam olarak doğru olmaz — ve olmaması bir arıza değildir.

Farkın kaynakları bellidir. Aktarım anlıktır ama anlık değildir: iki sistem arasında her zaman saniyelerden saatlere uzanan bir gecikme vardır ve o aralıkta sorulan her soru iki farklı cevap alır. Bir taraf kaydı değiştirdiğinde diğer taraf henüz eski hâli taşır. Bir aktarım yarıda kalır. Bir mesaj iki kez iletilir. Bir kayıt bir tarafta silinir, diğer tarafta silinmez.

Bunların hiçbiri önlenemez; yalnızca öngörülebilir. Sağlam bir entegrasyonu kırılgan olandan ayıran şey, farkın hiç oluşmaması değil, oluştuğunda ne olacağının tanımlı olmasıdır.

Kaynak sistem, sistem bazında değil alan bazında tanımlanır

"Hangisi ana sistem" sorusu entegrasyon toplantılarının klasiğidir ve genellikle yanlış sorudur. Cevap tek bir sistem olamaz, çünkü hiçbir sistem her alanda haklı değildir.

Doğru kurgu alan düzeyindedir. Müşterinin iletişim bilgisi satış sisteminde doğrudur, çünkü orada güncellenir. Kredi limiti finans sisteminde doğrudur. Stok adedi depo sisteminde doğrudur. Her alan için tek bir sistem "burada yazan doğrudur" yetkisine sahip olmalı, diğerleri o alanı yalnızca okumalıdır.

Bu tanım yapılmadığında ortaya çıkan davranış öngörülebilir: aynı alan iki yerden güncellenir ve son yazan kazanır. Bir kullanıcının dikkatle girdiği adres, bir saat sonra bir aktarımla eski hâline döner. Kullanıcı bunu bir kez yaşadığında sisteme olan güvenini kaybeder ve bilgiyi kendi tuttuğu bir yere yazmaya başlar — bu da dijital dönüşüm yazısındaki paralel sistemlerin nasıl kalıcı hâle geldiğini açıklar.

Alan bazında kaynak tanımının ikinci faydası tartışmayı bitirmesidir. Bir uyuşmazlık çıktığında hangi tarafın düzeltileceği baştan bellidir; kimse iki ekranı karşılaştırıp karar vermek zorunda kalmaz.

Yarım kalan işlem ve iki kez gelen mesaj

Entegrasyonların en pahalı hataları, tamamen başarısız olan aktarımlardan değil, yarım kalanlardan çıkar.

Sipariş bir tarafta oluşturulur, diğer tarafa yazılırken bağlantı kopar. Birinci sistemde sipariş vardır, ikincisinde yoktur. Hata kaydı bir yere düşmüşse fark edilir; düşmemişse aradaki fark aylarca büyür.

Bunun ikizi, aynı mesajın iki kez işlenmesidir. Aktarım başarısız sanılıp tekrarlandığında veya bir kuyruk mesajı yeniden gönderdiğinde, ikinci sistemde aynı sipariş iki kez oluşur. Bu, düzeltilmesi ilkinden daha zor bir durumdur, çünkü hangi kaydın fazlalık olduğu içeriğine bakılarak anlaşılmalıdır.

Çözüm ikisinde de aynı yerdedir: her aktarımın kendi kimliği olmalı ve alıcı taraf, daha önce işlediği bir kimliği tekrar işlememelidir. Bu, teknik olarak küçük bir karardır ve sonradan eklenmesi çok zordur — çünkü geçmiş kayıtlar bu kimliği taşımaz.

Hata nereye düşüyor?

Bir entegrasyonun en çok atlanan parçası, başarısız aktarımların nereye gittiğidir.

Çoğu kurulumda cevap şudur: bir log dosyasına. Yani pratikte hiçbir yere. Kimse o dosyaya bakmaz, çünkü bakması gereken kişi tanımlı değildir ve bir uyarı üretilmemiştir.

Sonuç, sessiz bir ayrışmadır. Sistem çalışıyor görünür, aktarımların yüzde biri düşer ve bu fark aylar boyunca birikir. Ay sonundaki üç siparişlik fark tam olarak böyle oluşur.

İşe yarayan kurgu basittir: başarısız aktarımlar görünür bir listede toplanmalı, bu listenin bir sahibi olmalı ve liste boş değilse bu bir durum olarak fark edilmelidir. Bu, otomasyonda işleyemediği vakayı ayıran sistem fikrinin (kısmi otomasyon) entegrasyon tarafındaki karşılığıdır.

Karşı sistem çökerse bu taraf durmalı mı?

Entegrasyon tasarımının en görünmez kararı, iki sistem arasındaki bağın ne kadar sıkı olacağıdır.

Sıkı bağlı bir kurguda işlem, karşı sistemin cevabı beklenerek tamamlanır. Sipariş, muhasebe sistemi onaylamadan kaydedilmez. Bu, verinin her an tutarlı olmasını sağlar ve bir bedeli vardır: karşı sistem yavaşladığında bu taraf da yavaşlar, çöktüğünde bu taraf da durur. Beş sistemin birbirine bu şekilde bağlandığı bir kurumda, çalışma süresi en zayıf halkanın çalışma süresidir.

Gevşek bağlı bir kurguda ise işlem kendi tarafında tamamlanır, aktarım bir kuyruğa yazılır ve karşı taraf hazır olduğunda işlenir. Sipariş alınmaya devam eder; muhasebe sistemi bir saat sonra geri geldiğinde birikmiş kayıtları işler. Bunun bedeli de bellidir: iki sistem bir süre farklı şeyler bilir.

Doğru seçim işin doğasına bağlıdır ve alan bazında değişir. Stok düşümü gibi doğrudan para veya taahhüt üreten adımlarda beklemek makuldür. Bir raporlama sistemine bilgi göndermek için beklemek ise gereksizdir; orada bir dakikalık gecikmenin hiçbir maliyeti yoktur.

Asıl hata, bu kararın hiç verilmemesidir. Verilmediğinde varsayılan davranış neredeyse her zaman sıkı bağdır — çünkü yazması kolay olan odur — ve kurum, bunu ancak bir sistemin çökmesiyle birlikte diğer dördünün de durduğu gün fark eder.

Mutabakat sonradan yapılan bir iş değil, bir özelliktir

İki sistemin uyumlu olduğunu varsaymak yerine düzenli olarak karşılaştırmak, entegrasyon tasarımının en çok getiri sağlayan parçasıdır.

Bu, karmaşık bir mekanizma gerektirmez: belirli aralıklarla iki taraftaki kayıt sayıları ve toplamları karşılaştırılır, uyuşmayanlar listelenir. Önemli olan bu karşılaştırmanın bir insanın elle yaptığı bir iş değil, sistemin bir parçası olmasıdır.

Faydası çift yönlüdür. Farklar küçükken ve nedeni hâlâ hatırlanabilirken yakalanır; ayrıca sistemin doğru çalıştığına dair kanıt üretir. Mutabakatı olmayan bir entegrasyonda kimse sistemin doğru çalıştığını bilemez — yalnızca aksini gösteren bir şey görmemiştir.

Sonuç

Entegrasyon, iki sistemi birbirine bağlamak değil, iki sistemin aynı gerçeklik üzerinde anlaşmasını sağlamaktır. Bağlantı kurmak günler alır; anlaşmayı tanımlamak ise projenin asıl işidir ve genellikle en az zaman ayrılan kısmıdır.

Bu yüzden entegrasyon kalitesi, veri akıp akmadığıyla değil, akmadığında ne olduğuyla ölçülür. Kaynak sistemi alan bazında tanımlanmış, başarısız aktarımı görünür, mutabakatı otomatik bir kurgu; hata yaptığında bunu söyleyen bir sistemdir.

Söylemeyen sistemlerde ise hata birikir ve bir gün bir toplantıda, üç siparişlik bir fark olarak ortaya çıkar. Kurumsal yazılım ve otomasyon çalışmalarımızda entegrasyon tasarımı, alan eşleştirmesinden önce bu soruların cevaplanmasıyla başlar.