Kurumsal Sistem Entegrasyonu: Bir Organizasyonu Çalıştıran Tesisat
Her organizasyon, birbirine konuşmak üzere hiç tasarlanmamış bir düzine sistem çalıştırır. Konuşana kadar entegrasyon katmanı insandır — ekranlar arasında veri kopyalayan. Sistem entegrasyonu, o insan yapıştırıcısını güvenilir, görünmez ve hastalanmayan bir tesisatla değiştirir.
Bir kurumun CRM'i, muhasebe sistemi, İK platformu ve şu kritik özel aracı arasında verinin nasıl aktığını sorun; dürüst cevap genelde aynıdır: biri kopyalıyor. Bir kişi buradan bir rapor export eder, oraya yapıştırır, zaten eşleşmesi gereken iki sayıyı mutabık kılar.
O kişi entegrasyon katmanıdır. Ve insan bir entegrasyon katmanı yavaş, hataya açık ve işin en büyük gizli maliyetlerinden biridir. Sistem entegrasyonu, onu sistemleri doğrudan birbirine bağlayan yazılımla değiştirme disiplinidir.
DZDSoft'ta entegrasyon — ağ kurulumları, sunucu provisioning ve sistemler arası bağ dokusu — yaptığımız en az gösterişli ama en değerli işlerden biridir. Gerçekte nasıl çalıştığı aşağıda.
Kopuk bir kurumun belirtileri
Organizasyon şemasında nadiren bir "entegrasyon problemin" olur. Belirtilerin olur ve pahalıdırlar:
- Aynı veri iki sisteme iki kez girilir ve birbirinden uzaklaşırlar.
- Raporlar elle mutabakat gerektirir çünkü hiçbir iki sistem aynı fikirde değildir.
- Bir sayı araçlar arasında her gün kopyala-yapıştır edilir ve ara sıra yanlıştır.
- Tek bir çalışanı işe almak, beş ayrı sisteme elle dokunmak demektir.
- Kimse tek bir sistemin doğru olduğuna güvenmez, herkes kendi excel'ini tutar.
Bunların her biri, bir insanın yazılımın yapması gerekeni yaptığı yerdir. Bir şirket boyunca toplayın; maliyet, tam bir rol dolusu zamandır — işe değil, tesisata harcanan.
Entegrasyon yelpazesi
"Sadece sistemleri bağla" gerçek mimari seçimleri gizler ve yanlış olanı bir yıl içinde kendi problemine dönüşür.
| Yaklaşım | Ne demek | Ödünü |
|---|---|---|
| Point-to-point | Her sistem çifti arasında doğrudan bağlantı | Birkaç sistem için hızlı; çoğaldıkça karmakarışık bir ağa döner |
| Middleware / ESB | Tüm sistemlerin bağlandığı merkezî bir hub | Ölçekte daha temiz; hub'ın kendisi kurulmalı ve bakılmalı |
| API-led | Yeniden kullanılabilir API'ler her sistemin verisini açar | En esnek ve dayanıklı; disiplin ve önden tasarım ister |
Doğru cevap kaç sistemin olduğuna ve bu sayının ne hızla büyüdüğüne bağlıdır. Point-to-point üç sistem için iyi, on beş için kâbustur. Hata modu, hızlı point-to-point bağlantılarla başlayıp iki yıl sonra bakımı imkânsız bir ağın içinde uyanmaktır.
Çoğunlukla veriyle — ve kimlikle — ilgili
Yüzeyin altında entegrasyon iki problemdir: sistemleri veride anlaştırmak ve ona kimin dokunabileceğinde anlaşmak.
Veri yarısı, her kayıt türü için bir tek doğru kaynak (single source of truth) tanımlamak — müşteriye CRM'in, çalışana İK'nın sahip olduğuna karar vermek — ve geri kalanı onunla senkron tutan hatları (ETL, API, webhook) kurmaktır.
Kimlik yarısı, SSO/LDAP ve Active Directory'nin neden önemli olduğudur: bir kişi katıldığında, rol değiştirdiğinde ya da ayrıldığında, bu her bağlı sisteme otomatik yayılmalı. Doğru yapılmış kimlik hem bir güvenlik kontrolü hem bir entegrasyon omurgasıdır — entegrasyon işinin veri güvenliğine tam da dokunduğu yer.
Kimsenin görmediği zor kısımlar
Entegrasyon bir diyagramda basit görünür — iki kutu arasında bir çizgi. Zorluk, o çizginin gizlediği her şeydir:
- Modern API'si olmayan, yalnızca bir veritabanı ya da dosya bırakımı olan legacy sistemler.
- Error handling — bir sistem senkron ortasında çöktüğünde ne olur, veriyi çoğaltmadan ya da kaybetmeden nasıl toparlarsın.
- Idempotency — yeniden denenen bir işlemin iki kez çalışmamasını sağlamak.
- Ertesi sabah bir rapor yanlış çıkana kadar kimsenin fark etmediği gece 2'deki senkron hatası.
Bir demoda çalışan bir entegrasyonu yıllarca çalışan bir entegrasyondan ayıran gösterişsiz mühendislik budur. Yanlış yapmak kendini ilan etmez — aylar sonra sessizce bozulmuş veri olarak ortaya çıkar.
Sistem entegrasyonuna ihtiyacın var mı?
İşaretler genelde göz önünde saklıdır:
Biz nasıl yaklaşıyoruz?
Entegrasyonu bir özellik değil, altyapı olarak ele alıyoruz. Yani gösterişsiz sorularla başlıyoruz — hangi sistem hangi veriye sahip, biri çöktüğünde ne olur, kimlik nasıl akar — tek satır bağ kodu yazmadan önce. Zor tesisatı biz üstleniriz: legacy bağlantıları, error handling'i, eski yöntemden yeniye boşluksuz cutover'ı ve bir şey ters giderse rollback'i.
Diğer işlerimizdeki aynı ilke: sistemlerini haritalayan mühendis, entegrasyonu kuran kişidir; çünkü değer, tamamen bir diyagramın dışarıda bıraktığı ayrıntılardadır.
- Sistemler entegre olana kadar entegrasyon katmanı veri kopyalayan insanlardır — yavaş, pahalı, hataya açık.
- "Sadece bağla" gerçek seçimleri gizler: point-to-point, middleware/ESB, API-led — ve yanlışı karmaşaya döner.
- Entegrasyon iki problemdir: veri için tek doğru kaynak ve kimlik (SSO/LDAP/Active Directory).
- Zor kısımlar görünmez: legacy sistemler, error handling, idempotency, sessiz gece 2 hatası.
- Entegrasyonu altyapı olarak ele al — bağ kodu yazmadan önce sahiplik ve hata modlarını haritala.
- İnsanlar rutin olarak iki ya da daha fazla sistemin arasında veri kopyalıyorsa.
- Raporlar, kimse güvenmeden önce elle mutabakat gerektiriyorsa.
- Birini işe alma/çıkarma, birkaç sistemi elle güncellemek demekse.
- İyi yazılım almışsın ama hâlâ diğer iyi yazılımınla konuşmuyorsa.
- Her ekip özel bir excel tutuyorsa çünkü hiçbir sistem üzerinde anlaşılan doğru değil.
- Sistemler entegre olana kadar entegrasyon katmanı veri kopyalayan insanlardır — yavaş, pahalı, hataya açık.
- "Sadece bağla" gerçek seçimleri gizler: point-to-point, middleware/ESB, API-led — ve yanlışı karmaşaya döner.
- Entegrasyon iki problemdir: veri için tek doğru kaynak ve kimlik (SSO/LDAP/Active Directory).
- Zor kısımlar görünmez: legacy sistemler, error handling, idempotency, sessiz gece 2 hatası.
- Entegrasyonu altyapı olarak ele al — bağ kodu yazmadan önce sahiplik ve hata modlarını haritala.
