Sistemler birbirini tanımaz, çünkü hiçbiri diğerini düşünerek kurulmamıştır. Her biri ayrı bir ihtiyaç için, ayrı bir zamanda, çoğu zaman ayrı bir ekip tarafından seçilmiştir; aradaki boşluğu da insanlar doldurur.

Bu boşluk zamanla bir borca dönüşür: entegrasyon borcu. Teknik borç gibi görünmez faiz işletir ve her yeni sistemle büyür.

Entegrasyon borcu nedir?

Bir verinin bir sistemden diğerine elle taşınması, aynı bilginin iki yerde ayrı ayrı güncellenmesi, raporun her ay farklı tablolardan yeniden derlenmesi: bunların hepsi entegrasyon borcunun taksitleridir. Kurum çalışmaya devam eder, ama her taksit zaman, dikkat ve hata riski olarak ödenir.

Borcun belirtileri tanıdıktır:

  • Çift kayıt: Müşteri bilgisi CRM'de, muhasebede ve bir tabloda ayrı ayrı tutulur; hangisinin doğru olduğu bilinmez.
  • Kopyala yapıştır iş akışı: Bir sistemden alınan çıktı elle diğerine girilir.
  • Tek kişiye bağlı köprü: İki sistemi birbirine bağlayan bilgi bir çalışanın alışkanlığıdır; o kişi izne çıktığında süreç durur.
  • Gecikmeli görünürlük: Yönetim bugünün durumunu ancak ay sonunda, birleştirilmiş raporla görür.
  • Kırılgan bağlantılar: Bir zamanlar kurulmuş, belgelenmemiş bir aktarım bir gün sessizce çalışmayı bırakır.
Entegrasyon borcu, iki sistemin arasında çalışan insanın zamanıyla ödenir.

Neden birikir?

Çünkü her araç kendi başına makul bir karardır. Satış ekibi bir CRM seçer, finans bir muhasebe programı, operasyon bir takip aracı. Kararların hiçbiri yanlış değildir; eksik olan, bu sistemlerin birlikte nasıl çalışacağına dair bir karardır. Entegrasyon sonradan düşünüldüğünde ya hiç yapılmaz ya da aceleyle, belgelenmeden yapılır.

Yeni bir sistem seçerken sorulacak ilk soru "ne yapıyor?" değil, "neyle konuşuyor?" olmalıdır.

Borç nasıl kapatılır?

Bütün sistemleri bir anda değiştirmek ne gerekli ne de akıllıcadır. Borç, en yüksek faizli taksitten başlayarak kapatılır:

  • 1. Harita: Sistemler, tuttukları veri ve aralarındaki elle yapılan aktarımlar listelenir. Her aktarım için sıklık ve harcanan zaman yazılır.
  • 2. Tek doğruluk kaynağı: Her veri türü için (müşteri, ürün, fatura) asıl kaydın hangi sistemde tutulduğuna karar verilir. Diğer sistemler bu kaynaktan okur.
  • 3. Belgelenmiş arayüzler: Sistemler arası bağlantılar, versiyonlanmış ve belgelenmiş API'lerle kurulur. Bir bağlantının ne taşıdığı, ne sıklıkla çalıştığı ve kimin sorumluluğunda olduğu yazılıdır.
  • 4. Hata görünürlüğü: Bir aktarım başarısız olduğunda bunu ilk fark eden, ay sonundaki rapor değil, bir uyarı olmalıdır.
  • 5. Önceliklendirme: En çok zaman alan ve en çok hata üreten aktarım ilk otomatikleştirilir; geri kalanı sıraya girer.

Yeni sistem alırken sorulacaklar

  • Belgelenmiş bir API'si var mı, hangi verilere erişim veriyor?
  • Veriyi toplu olarak dışa aktarmak mümkün mü?
  • Olay bildirimi (webhook) gönderebiliyor mu?
  • Kimlik ve yetki yönetimi mevcut sistemlerle uyumlu mu?
  • Bu sistem bırakılırsa veri nasıl taşınır?

Entegrasyon yalnız verinin taşınması değildir; kurum bilgisinin bir arada tutulmasıdır. Bilgi bir araya geldiğinde, kurumsal bilgi sistemleri ve otomasyon gibi sonraki adımlar da mümkün hale gelir.

Kurumunuz için benzer bir çalışmayı konuşmak isterseniz: System Architecture · İletişim

Systems do not recognize each other because none of them was set up with the others in mind. Each was chosen for a separate need, at a separate time, often by a separate team; people fill the gap between them.

Over time that gap becomes a debt: integration debt. Like technical debt, it charges invisible interest and grows with every new system.

What is integration debt?

Moving data from one system to another by hand, updating the same information in two places, rebuilding a report from different spreadsheets every month: all of these are instalments of integration debt. The organization keeps working, but each instalment is paid in time, attention and risk of error.

The symptoms are familiar:

  • Double entry: Customer data is kept separately in the CRM, in accounting and in a spreadsheet; nobody knows which one is right.
  • Copy-paste workflows: Output taken from one system is entered into another by hand.
  • A bridge tied to one person: The knowledge that connects two systems is one employee's habit; when that person is on leave, the process stops.
  • Delayed visibility: Management sees today's situation only at month end, in a merged report.
  • Fragile connections: A transfer set up long ago and never documented one day quietly stops working.
Integration debt is paid with the time of the person working between two systems.

Why does it build up?

Because every tool is a reasonable decision on its own. Sales chooses a CRM, finance an accounting package, operations a tracking tool. None of these decisions is wrong; what is missing is a decision about how these systems will work together. When integration is thought of afterwards, it is either never done or done in a hurry and without documentation.

When choosing a new system, the first question should not be "what does it do?" but "what does it talk to?"

How is the debt paid off?

Replacing every system at once is neither necessary nor wise. The debt is paid off starting with the instalment carrying the highest interest:

  • 1. Map: List the systems, the data they hold and the manual transfers between them. Note the frequency and time spent for each transfer.
  • 2. Single source of truth: For each type of data (customer, product, invoice), decide which system holds the master record. Other systems read from that source.
  • 3. Documented interfaces: Connections between systems are built with versioned, documented APIs. What a connection carries, how often it runs and who is responsible for it is written down.
  • 4. Error visibility: When a transfer fails, the first to notice should be an alert, not the month-end report.
  • 5. Prioritization: The transfer that takes the most time and produces the most errors is automated first; the rest join the queue.

Questions to ask when buying a new system

  • Does it have a documented API, and which data does it give access to?
  • Can data be exported in bulk?
  • Can it send event notifications (webhooks)?
  • Is identity and access management compatible with existing systems?
  • If the system is dropped, how is the data moved?

Integration is not just moving data; it is keeping the organization's knowledge together. Once knowledge comes together, next steps such as enterprise knowledge systems and automation become possible too.

If you would like to discuss similar work for your organization: System Architecture · Contact