Orta ve büyük ölçekli kurumların çoğu, farklı zamanlarda farklı tedarikçilerden satın alınmış birkaç çekirdek sistem kullanır. ERP finans ve tedarik verisini, CRM müşteri etkileşimlerini tutar. Sağlık sektöründe ise hastane bilgi yönetim sistemi (HBYS, uluslararası kullanımıyla HIS) hasta kayıtlarını, istemleri ve faturalamayı barındırır. Bu sistemleri birbirine bağlamak bir projenin en görünür kısmı olmasa da projenin zamanında bitip bitmeyeceğini çoğu zaman belirler. Bu yazıda en sık karşılaşılan sorunlar ve bunları azaltan uygulamalar ele alınmaktadır.

Entegrasyon projeleri neden gecikir

Entegrasyon tahminleri genellikle iyimser kalır, çünkü işin zorlukları başlayana kadar görünmez. Dört neden sürekli karşımıza çıkar.

  • Dokümante edilmemiş alanlar. Bir tabloda amacı kimsenin hatırlamadığı bir kolon bulunur ve anlamını öğrenmenin tek yolu, yıllar önce yapılandırmayı yapan kişiye sormaktır.
  • İki ayrı doğruluk kaynağı. Müşteri veya ürün verisi iki sistemde de bulunur ve iki kopya birbiriyle uyuşmaz. Hangisinin hangi kurallar altında geçerli sayılacağına birinin karar vermesi gerekir.
  • Toplu aktarım ve gerçek zamanlı beklentileri. İş kullanıcısı güncel veri ister, kaynak sistem yalnızca gece dışa aktarım yapabilir ve aradaki fark geç fark edilir.
  • Tedarikçi kontrolündeki arayüzler. Hangi arayüzlerin sunulacağına, ne kadar ücretlendirileceğine ve ne zaman değişeceğine tedarikçi karar verir. Bu nedenle entegrasyon ekibi dış takvimlere bağımlı kalır.

Arayüz seçenekleri

Arayüz seçimi, kaynak sistemin neyi desteklediğine ve verinin ne kadar güncel olması gerektiğine bağlıdır. REST ve SOAP web servisleri, modern ERP ve CRM ürünlerinde en yaygın yoldur. İstek ve yanıt temelli veri alışverişini destekler ve izlenmesi kolaydır, ancak kaynak sistemin doğru operasyonları sunmasını gerektirir.

Dosya alışverişi hâlâ yaygındır. Zamanlanmış CSV veya XML çıktıları basit ve dayanıklıdır, raporlama ve gece senkronizasyonu için uygundur. Mesaj kuyrukları gönderen ile alıcıyı birbirinden ayırır. Böylece taraflardan biri bir süre erişilemez olsa bile veri kaybı yaşanmaz. Sıranın ve teslimatın önemli olduğu olay tabanlı akışlar için uygundur.

Sağlık verisinde kabul, sipariş ve sonuç mesajları için HL7 sürüm 2 hâlâ yaygın biçimde kullanılmaktadır. API tabanlı veri alışverişinde ise FHIR giderek daha fazla tercih edilmektedir. Bu standartların kullanılması özel eşleme ihtiyacını azaltır. Yine de yerel profillerin ve uzantıların her tedarikçiyle ayrıca kararlaştırılması gerekir.

Veri eşleme ve veri kalitesi

Eşleme, işin çekirdeğidir. Her alan için kaynak, hedef, dönüşüm ve çakışma durumunda uygulanacak kural kaydedilir. Kod listeleri, ölçü birimleri, tarih formatları, karakter kodlamaları ve tanımlayıcılar özel dikkat gerektirir, çünkü bir hasta, müşteri veya ürün her sistemde farklı bir tanımlayıcı taşıyabilir.

Veri kalitesi sorunları genellikle bu aşamada ortaya çıkar. Mükerrer kayıtlar, eksik zorunlu değerler ve kod olarak kullanılan serbest metin alanları bunlara örnektir. Bu sorunları kaynakta, veri sahipleriyle üzerinde anlaşılan temizleme kurallarıyla çözmek en doğrusudur. Arayüzün içinde yama yapmak sorunları görünmez hale getirir.

Güvenlik ve denetim izi

Entegrasyon hesapları en az yetki ilkesine göre tanımlanmalı, erişim arayüzün ihtiyaç duyduğu operasyonlarla sınırlandırılmalıdır. Kişisel veriyi okuyan veya değiştiren her çağrı, kim tarafından, neyi ve ne zaman yaptığı bilgisiyle loglanmalı, loglar korunmalı ve politikaya uygun süre boyunca saklanmalıdır.

Kişisel veriler Türkiye'de KVKK, AB'de GDPR kapsamındadır. Sağlık verisi için gereklilikler daha katıdır. Entegrasyon tasarımında hangi verinin hangi amaçla aktarıldığı, aktarım sırasında ve saklanırken nasıl korunduğu ve kopyaların ne kadar süre tutulduğu tanımlanmalıdır.

Test ve geri dönüş planı

Arayüzler gerçekçi veriyle test edilmelidir. Uzun isimler, özel karakterler, iptal edilmiş siparişler ve düzeltilmiş sonuçlar gibi uç durumlar da bu teste dahil edilmelidir. Her iki sistemin canlı ortamdaki sürümlerini yansıtan test ortamları değerlidir, çünkü davranış sürümler arasında sıklıkla farklılık gösterir. Geçiş planında adımların sırası, her adımdan sonra yapılacak kontroller ve ekibin önceki duruma döneceği koşullar yer almalıdır.

Canlıya aldıktan sonra işletme

Bir arayüz, çalışan bir servistir. Hataların ve gecikmelerin izlenmesi, reddedilen mesajların incelenip yeniden gönderilebileceği bir hata kuyruğu ve adı belli bir kişiye ulaşan uyarılar gerekir. Her arayüzün iş tarafında ve teknik tarafta birer sorumlusu olmalı, amacını, çalışma takvimini, eşlemesini ve bilinen sınırlarını anlatan bir dokümantasyon bulunmalıdır. Bunlar olmadığında küçük hatalar birikir ve zamanla iki sistemdeki veriler birbiriyle uyuşmaz hale gelir.