# Saha Notu: Entegrasyon Aşamasında Beklenmeyen Gecikmeler > Source: https://sukruyusufkaya.com/blog/saha-notu-entegrasyon-gecikmeleri > Updated: 2026-08-23T23:11:15.782Z > Type: blog > Category: yapay-zeka **TLDR:** Entegrasyon gecikmesi deneyimi: sahadan bir saha notu. Eski sistem API'leri, test ortamı yokluğu ve veri eşleme istisnaları proje takvimini neden kaydırır? Bu bir saha notu. Yani teoriden değil, kurumsal yapay zeka projelerinin en az konuşulan ama en çok takvim kaydıran aşamasından — entegrasyondan — birinci ağızdan bir aktarım. Model çalışıyordu, demo herkesi memnun etmişti, ekip rahatlamıştı. Sonra "artık sadece bağlayalım" dendi ve proje aylarca orada takıldı. Bu yazı, o "sadece bağlayalım" cümlesinin arkasında sahada gördüğüm entegrasyon gecikmesi deneyimini ve bu gecikmelerin neden teknik değil, büyük ölçüde örgütsel olduğunu anlatıyor. Yazının amacı, entegrasyon gecikmelerini kaçınılmaz bir kader gibi değil, önceden görülebilir ve büyük ölçüde önlenebilir bir örüntü olarak göstermek. Her gecikme kaynağının bir belirtisi ve bir önleyici aksiyonu var; bunları bir gecikme kaynağı × belirti × önleyici aksiyon tablosunda toplayacağım. Uydurma bir vaka ya da hayali bir sayı vermeyeceğim; anlattığım her şey, tekrar tekrar gördüğüm örüntülerden damıtılmış saha gözlemidir. ## Entegrasyon Gecikmesi Deneyimi: Sahadan Bir Giriş Bir yapay zeka projesinin ilerleyişini bir buzdağına benzetmek isterim. Suyun üstünde görünen, herkesin konuştuğu kısım modeldir: doğruluk, prompt, mimari. Suyun altındaki, projeyi asıl batıran kısım ise entegrasyondur. Sahadaki entegrasyon gecikmesi deneyimimin çoğu buradan gelir: çözümün kalbi hazırdır, ama onu kurumun gerçek sistemlerine bağlamak beklenenden kat kat uzun sürer. Bunun sebebini yıllar içinde şöyle özetledim: model tarafı sizin kontrolünüzdedir, entegrasyon tarafı ise başkalarının kontrolündedir. Kendi kodunuzu istediğiniz gibi düzeltirsiniz; ama bağlanacağınız eski sistem başka bir ekibin, başka bir tedarikçinin veya başka bir kurumun elindedir. İşte entegrasyon gecikmesi deneyiminin özü bu devir teslimde, bu "başkasına bağımlı olma" durumunda gizlidir. Kod yazmak hızlıdır; başkasının müsait olmasını beklemek yavaştır. Bu ayrımı erken görmek önemli, çünkü çözüm de buradan çıkıyor. Teknik bir gecikmeyi daha iyi mühendislikle kısaltabilirsiniz; ama örgütsel bir gecikmeyi ancak koordinasyon, erken keşif ve gerçekçi planlama ile kısaltabilirsiniz. Yapay zeka projelerinin pilottan üretime geçerken neden takıldığını daha geniş çerçevede PoC'den üretime yapay zeka projeleri ve PoC'den production'a AI engineering hataları yazılarında ele alıyorum; bu saha notu ise o resmin tek bir parçasına, entegrasyona odaklanıyor. Bir noktayı baştan netleştireyim: entegrasyon gecikmesi deneyimi bir yeteneksizlik göstergesi değildir. En iyi ekipler bile bu gecikmeleri yaşar; fark, iyi ekiplerin gecikmeyi erken, küçük ve yönetilebilir yaşaması, deneyimsiz ekiplerin ise geç, büyük ve panik içinde yaşamasıdır. Bu yazının vaadi de bu: aynı gecikmeleri erkene çekmek ve küçültmek. Bu yazıyı bilinçli olarak birinci tekil şahısla, bir saha notu formatında yazıyorum. Çünkü entegrasyon gecikmeleri, ders kitaplarında değil, gerçek projelerin çamurunda öğrenilir. Aktardığım her örüntü, farklı sektörlerde tekrar tekrar karşılaştığım durumların damıtılmış hâlidir. Belirli bir müşteriyi, belirli bir sayıyı ya da uydurma bir vakayı anlatmıyorum; tekrar eden bir gerçeği anlatıyorum. ## Teknik Olmayan Gecikme Kaynakları Entegrasyon deyince akla ilk gelen, iki sistemi birbirine bağlayan kod olur. Oysa entegrasyon gecikmesi deneyimimin belki de en şaşırtıcı yanı şu: gecikmelerin çoğu koddan değil, kodun etrafındaki insan ve süreç katmanından çıkar. Teknik iş genellikle en kısa süren kısımdır; asıl zaman, teknik olmayan kaynaklarda kaybolur. Bu teknik olmayan gecikme kaynaklarını yıllar içinde birkaç başlıkta toplayabildim. Birincisi bekleme: bağlanacağınız sistemin sahibi müsait olana kadar hiçbir şey ilerlemez. İkincisi belirsizlik: kimin neye yetkili olduğu, hangi sistemin hangi veriyi tuttuğu, kime sorulacağı net değildir. Üçüncüsü onay: bir sisteme dokunmak için güvenlik, hukuk veya yönetim onayı gerekir ve bu onaylar kuyrukta bekler. Dördüncüsü koordinasyon: farklı ekiplerin takvimleri çakışmaz, herkes başka bir işle meşguldür. Bunların ortak özelliği, hiçbirinin daha iyi bir modelle ya da daha hızlı bir sunucuyla çözülememesidir. Bir mühendisi iki katına çıkarmak, karşı sistemin sahibini daha erken müsait yapmaz. İşte bu yüzden entegrasyon gecikmesi deneyimini yönetmek, bir mühendislik problemi değil, bir proje yönetimi ve iletişim problemidir. Sahada en büyük hatam, bu kaynakları teknik problem sanıp teknik çözüm aramaktı; oysa çözüm erken konuşmak, erken sormak ve erken denemektir. Bir başka teknik olmayan kaynak da bilgi kaybıdır. Kurumların büyük kısmında, bağlanacağınız sistemin nasıl çalıştığını bilen kişi ya emekli olmuş, ya işten ayrılmış, ya da başka bir departmandadır. Sistem çalışır ama kimse tam olarak nasıl çalıştığını bilmez. Bu "kurumsal hafıza boşluğu", entegrasyon gecikmesi deneyiminin sessiz ama güçlü bir bileşenidir; çünkü belgesiz bir sistemi anlamak, sıfırdan yazmaktan bazen daha uzun sürer. Veri tarafındaki bu belirsizlikleri daha geniş ele alan veri yönetişimi nedir yazısı, sorunun kökenini görmek için iyi bir çerçeve sunar. ## Karşı Sistem Tedarikçisinin Müsaitliği Sahada en sık karşılaştığım tek gecikme kaynağını seçmem gerekseydi, adı "karşı sistem beklemesi" olurdu. Entegrasyon, tanımı gereği iki taraflıdır: siz bir tarafı yazarsınız, ama bağlanacağınız karşı sistemin de bir sahibi vardır ve o sahibin müsaitliği sizin takviminizi doğrudan belirler. Karşı sistem beklemesi, entegrasyon gecikmesi deneyiminin belki de en kaçınılmaz görünen ama aslında en yönetilebilir parçasıdır. Karşı sistem beklemesi somut olarak şöyle görünür: bir soru sorarsınız — "bu alan neyi ifade ediyor", "test kullanıcısı açabilir misiniz", "şu uç noktaya erişim izni verir misiniz" — ve cevap günler, bazen haftalar sonra gelir. Çünkü o sistemin sahibi, sizin projenizi kendi öncelik listesinin en üstüne koymak zorunda değildir; kendi işleri, kendi bakımı, kendi acil durumları vardır. Sizin için kritik olan entegrasyon, onlar için sıradan bir talep kuyruğundaki bir kayıttır. Bu bekleme özellikle karşı sistem bir dış tedarikçinin elindeyse büyür. İç ekiplerle en azından aynı kurum içindesinizdir; dış tedarikçiyle araya sözleşme, ticari öncelik ve resmi talep süreçleri girer. "Küçük bir değişiklik" dediğiniz şey, tedarikçi tarafında bir iş emri, bir teklif, bir onay ve bir planlama döngüsüne dönüşür. Karşı sistem beklemesi burada saatlerden haftalara uzar. Bu gecikmeyi tamamen ortadan kaldıramazsınız, ama küçültebilirsiniz. Sahada işe yarayan yaklaşımım şu oldu: karşı sistemin sahibini projenin ilk gününde masaya oturtmak, ona ihtiyaç duyacağım her şeyi (erişim, belge, test kullanıcısı, örnek veri) tek seferde ve yazılı listelemek, ve her talep için gerçekçi bir cevap süresi üzerinde anlaşmak. Böylece karşı sistem beklemesini takvime baştan yazarım; sürpriz olmaktan çıkar, planlanmış bir bağımlılık hâline gelir. Bu koordinasyonun kurumsal mimari içindeki yerini kurumsal yapay zeka mimarisi yazısında bütünsel olarak ele alıyorum. Entegrasyon planlarken yapılan en yaygın hata, karşı sistemin taleplerinize hızlı döneceğini varsaymaktır. Sahada bu varsayım neredeyse her zaman yanlış çıkar. Doğru varsayım tersidir: karşı sistem beklemesi olacaktır, tek soru ne kadar. Planınızı bu gerçeğe göre kurun; her dış talep için tampon süre bırakın ve kritik taleplerinizi mümkün olan en erken tarihte iletin. Beklemeyi yok edemezsiniz, ama erken başlatarak paralel hâle getirebilirsiniz. ## Test Ortamı Yokluğu Eğer entegrasyon gecikmesi deneyimimin en pahalı tek kalemini işaretlemem istenseydi, tereddütsüz "test ortamı yokluğu" derdim. Entegrasyonun doğası deneme-yanılmadır: bir istek gönderirsiniz, dönen yanıta bakarsınız, bir şeyi düzeltir, tekrar denersiniz. Bu döngüyü güvenle çalıştırabileceğiniz, üretimden izole bir test ortamı yoksa, entegrasyonun bütün ritmi bozulur. Test ortamı yokluğu birkaç farklı biçimde karşınıza çıkar. Bazen hiç test ortamı yoktur; sadece üretim vardır ve üretim üzerinde deneme yapmak, gerçek müşteriyi, gerçek veriyi ve gerçek işleyişi riske atmak demektir. Bazen bir test ortamı vardır ama gerçek veriyi yansıtmaz; içi boştur ya da örnek verisi gerçek hayattaki istisnaları içermez, bu yüzden testte her şey yolunda görünür, üretimde patlar. Bazen de test ortamı vardır ama ona erişim izni bir onay kuyruğunun arkasındadır; ortam durur ama siz kullanamazsınız. Test ortamının yokluğu gecikmeyi iki koldan büyütür. Birincisi doğrudan yavaşlamadır: üretim üzerinde çalışmak zorunda kaldığınızda her deneme için onay beklersiniz, dikkatli ve yavaş ilerlersiniz, çünkü bir hatanın maliyeti gerçektir. İkincisi gizli gecikmedir: gerçekçi bir test ortamı olmadığı için veri eşleme istisnalarını, hız limitlerini ve kimlik doğrulama sorunlarını geç keşfedersiniz; bu sorunlar en kötü anda, üretime geçerken patlar. Yani test ortamı yokluğu, başka gecikmeleri de tetikleyen bir çarpan gibidir. Sahada öğrendiğim ders net: bir entegrasyon projesine başlarken sorduğum ilk üç sorudan biri "kullanabileceğim, gerçekçi veriye sahip, izin verilmiş bir test ortamı var mı" olur. Cevap "hayır" ise, projenin ilk teknik işi bu ortamı kurmaktır — model çalışmasından bile önce. Çünkü test ortamı olmadan entegrasyonu ilerletmeye çalışmak, gözleri kapalı araba sürmeye benzer; her an bir duvara çarpabilirsiniz ve çarptığınızda bu üretimde olur. Bu ortamın kurulması ve izlenmesi, üretim disiplininin bir parçasıdır; MLOps nedir ve üretimdeki sistemlerin ayakta kalması için model izleme ve drift yazıları bu disiplinin çerçevesini verir. ## Veri Eşlemede Keşfedilen İstisnalar İki sistemi bağlarken en çok hafife alınan iş, veri eşlemedir. Kağıt üzerinde çok masum görünür: bir sistemdeki alanları, diğer sistemdeki karşılıklarıyla eşleştirirsiniz. "Müşteri adı buraya, sipariş numarası şuraya." Bir tabloya sığar, bir toplantıda biter gibi durur. Oysa entegrasyon gecikmesi deneyimimin en sinsi bölümlerinden biri tam olarak burada, veri eşlemenin detayında saklıdır. Gerçek gecikme, eşlemenin kendisinde değil, eşleme sırasında keşfedilen istisnalarda ortaya çıkar. Sahada tekrar tekrar gördüğüm istisnalar şunlar: iki sistem aynı kavramı farklı adlandırır (bir tarafta "müşteri", diğer tarafta "hesap sahibi", ama tam olarak aynı şey değildir). Aynı alan bir tarafta zorunludur, diğer tarafta boş bırakılabilir; boş kaydı işlemeye çalıştığınızda entegrasyon durur. Tarih biçimleri uyuşmaz; bir sistem gün-ay-yıl, diğeri yıl-ay-gün kullanır ve bu fark sessizce yanlış veri üretir. Kimlik numarası formatları, para birimi gösterimleri, ondalık ayraçları farklıdır. Bir tarafta tek kayıt olan şey, diğer tarafta çoklu kayıttır. Bu istisnaların ortak özelliği, tasarım toplantısında görünmemeleridir. Toplantıda herkes "temiz" örneği düşünür: dolu, düzgün, kurallara uyan bir kayıt. İstisnalar ise gerçek veride yaşar — boş bırakılmış alanlar, eski kayıtlardaki tutarsızlıklar, elle girilmiş hatalı veriler, sisteme yıllar önce farklı kurallarla girilmiş kayıtlar. Bu yüzden veri eşleme, gerçek örnek veriyle denenmeden asla "bitti" sayılamaz. Bu tür biçim ve tanım uyuşmazlıklarının teknik yönünü veri tipi uyumsuzluğu ve zamanla değişen alan yapılarını schema drift yazılarında ele alıyorum. Veri eşlemedeki istisnaları küçültmenin en etkili yolu, onları erken görmektir. Bu yüzden sahada, veri eşlemeyi projenin sonuna değil başına koyarım ve mümkün olan en gerçekçi örnek veriyle test ederim. Bir avuç gerçek kayıtla yapılan iki saatlik bir deneme, aylar sonra üretimde patlayacak bir gecikmeyi baştan yakalayabilir. Verinin genel kalitesini ölçmek için veri kalitesi nedir yazısı, bu erken keşif disiplininin temelini sağlar. ## Güvenlik Gözden Geçirme Kuyruğu Teknik iş bittiğinde proje bitmez. Entegrasyon gecikmesi deneyimimde en çok "ama biz kodu bitirmiştik" cümlesini duyduğum aşama, güvenlik ve veri erişim izni gözden geçirmesidir. Çünkü bir sisteme bağlanmak, veri erişim izinleri almak ve özellikle kişisel veri içeren alanlara dokunmak, sadece teknik bir iş değildir; güvenlik, hukuk ve uyum ekiplerinin onayını gerektiren bir kuyruktur. Bu kuyruğun kendine ait bir hızı vardır ve bu hız sizin kontrolünüzde değildir. Güvenlik ekibi, bağlanmak istediğiniz her sistemi, isteyeceğiniz her erişimi ve dokunacağınız her veriyi değerlendirir; bu değerlendirme, kurumun risk politikalarına, mevcut iş yüküne ve konunun hassasiyetine göre günler ya da haftalar sürebilir. Teknik iş bir günde bitse bile, gözden geçirme kuyruğu aynı hızda ilerlemez. Sahada yaptığım en pahalı hatalardan biri, bu kuyruğu geç başlatmaktı. Mantık şöyle işliyordu: "önce teknik işi bitirelim, sonra güvenlik onayı alırız." Sonuç, iki beklemenin üst üste binmesiydi — önce teknik iş, sonra sıfırdan başlayan onay kuyruğu. Öğrendiğim ders şu: güvenlik ve veri erişim izni gözden geçirmesini projenin ilk gününde, teknik işe paralel başlatmak. Böylece teknik iş bittiğinde onay da olgunlaşmış olur; iki bekleme ardışık değil, eşzamanlı yaşanır. Bu kuyruğun içeriği de önemli. Erişim izinleri, hangi kullanıcının hangi veriye erişebileceği, kişisel veri içeren alanların nasıl korunacağı, denetim kaydının nasıl tutulacağı — bunların hepsi baştan konuşulmalıdır. Türkiye bağlamında kişisel veri içeren entegrasyonlar KVKK yükümlülüklerini tetikler; bu çerçeveyi KVKK nedir ve KVKK uyumlu bir mimari için KVKK uyumlu yapay zeka nedir yazılarında ele alıyorum. Kimin ne zaman hangi veriye eriştiğini kaydeden audit trail katmanı, hem güvenlik hem uyum açısından bu kuyruğun beklediği temel unsurlardan biridir. Bulut mu, kendi altyapınız mı sorusunun bu kuyruğa etkisini self-hosted LLM vs API karar rehberi yazısında değerlendiriyorum. Güvenlik gözden geçirmesi bir teknik problem değil, bir sıra problemidir. Sıradaki yerinizi ancak erken girerek iyileştirebilirsiniz. Bu yüzden entegrasyon projelerinde güvenlik ve izin sürecini, kod yazmaya başladığınız gün başlatın. Gözden geçirme ekibine ne isteyeceğinizi erken ve net anlatın; bekledikleri belgeleri (veri akış şeması, erişim listesi, risk değerlendirmesi) önceden hazırlayın. Onay kuyruğunda beklemek kaçınılmazdır; ama o kuyruğa geç girmek, tamamen kendi elinizdeki bir gecikmedir. ## Eski Sistem API'leri, Kimlik Doğrulama ve Hız Limitleri Modern bir yapay zeka çözümünü kurumun gerçek dünyasına bağlarken, karşınıza çıkan sistemlerin çoğu modern değildir. Entegrasyon gecikmesi deneyimimin teknik olarak en zorlu tarafı, eski sistemlerle (legacy) çalışmaktır. Bu sistemler yıllar önce, farklı standartlarla, farklı ihtiyaçlar için kurulmuştur ve genellikle üç sorunu bir arada taşırlar: belgesizlik, eski kimlik doğrulama ve katı hız limitleri. Birinci sorun belgesizliktir. Eski bir sistemin API'si — eğer bir API'si varsa — çoğu zaman yazılı belgeye sahip değildir. Hangi uç noktanın ne döndürdüğü, hangi alanın ne anlama geldiği, hangi kodun hangi durumu temsil ettiği yazılı değildir. Bu bilgi, sistemi yıllar önce kuran kişinin aklındadır ve o kişi çoğu zaman artık kurumda değildir. Belgesiz bir sistemi anlamaya çalışmak, deneme-yanılmayla sürer ve her deneme karşı sistem beklemesine dönüşür. İkinci sorun eski kimlik doğrulamadır. Modern standartlar yerine, eski sistemler özel, kırılgan ve bazen belgelenmemiş oturum mekanizmaları kullanabilir. Bir jeton nasıl alınır, ne kadar geçerlidir, nasıl yenilenir — bunların hepsi keşfedilmesi gereken bilinmezlerdir. Kimlik doğrulama katmanındaki tek bir sürpriz, günlerce süren bir gecikmeye yol açabilir; çünkü çözemediğiniz sürece hiçbir istek geçmez. Üçüncü sorun katı hız limitleridir. Eski sistemler yüksek istek hacmine göre tasarlanmamıştır; bu yüzden dakikada ya da saniyede belirli sayıda çağrıya izin verirler. Modern çözümünüz saniyede yüzlerce istek göndermeye alışkınken, karşı sistem "dakikada on istek" diyorsa, bütün mimarinizi bu limite göre yeniden düşünmeniz gerekir. Toplu işleme, kuyruklama, önbellekleme gibi teknikler devreye girer ve bunlar planlanmadıysa gecikme kaçınılmazdır. Bu üç sorun tek başına yönetilebilir; ama birleştiklerinde her entegrasyon adımı bir engel koşusuna dönüşür. Sahada işe yarayan yaklaşımım, eski sistemin sahibini erken masaya oturtmak ve sistemin gerçek davranışını — belgeye değil, gerçek denemeye dayanarak — mümkün olan en erken keşfetmektir. Eski sistemlerle entegrasyonun mimari tuzaklarını daha geniş olarak PoC'den production'a mimari hatalar yazısında, modelleri araç ve verilere bağlayan protokolleri ise function calling nedir ve MCP nedir yazılarında ele alıyorum. ## Veri Erişim İzinleri ve Onay Zincirleri Entegrasyonun sık atlanan bir katmanı, teknik bağlantının kendisi değil, o bağlantıyı kurmaya "yetkili olma" meselesidir. Bir sisteme teknik olarak bağlanabiliyor olmanız, ona bağlanma iznine sahip olduğunuz anlamına gelmez. Veri erişim izinleri, entegrasyon gecikmesi deneyiminin görünmez ama güçlü bir bileşenidir; çünkü izinler bir kişinin değil, çoğu zaman bir onay zincirinin sonucudur. Bir onay zinciri şöyle işler: veriye erişmek için veri sahibinden izin istersiniz, veri sahibi bunu güvenliğe danışır, güvenlik hukuka sorar, hukuk uyuma yönlendirir. Her halka kendi hızında ilerler ve zincirin toplam süresi, en yavaş halkanın hızıyla belirlenir. Sahada gördüğüm örüntü şu: bu zincir baştan haritalanmazsa, her yeni onay ihtiyacı sürpriz bir gecikme yaratır ve proje adım adım yavaşlar. İzin meselesini karmaşıklaştıran bir başka gerçek, granülerliktir. "Sisteme erişim" tek bir şey değildir; hangi tabloya, hangi alana, hangi kayıt aralığına, hangi amaçla eriştiğiniz ayrı ayrı değerlendirilebilir. Özellikle kişisel veri içeren alanlarda, amaçla sınırlılık ve veri minimizasyonu ilkeleri gereği, yalnızca gerçekten ihtiyaç duyduğunuz veriye erişim verilir. Bu doğru bir yaklaşımdır ama entegrasyon planlamasında hesaba katılmalıdır. Kişisel verinin ne olduğunu kişisel veri nedir ve veri sahipliği kavramını veri sahipliği yazılarında ele alıyorum. Bu izin zincirlerini yönetmenin sahada işe yarayan yolu, onları teknik işten önce başlatmak ve her erişim talebini olabildiğince erken, net ve gerekçeli iletmektir. "Şu veriye şu amaçla, şu kadar süreyle, şu koruma önlemleriyle erişmek istiyorum" biçiminde net bir talep, zincirdeki her halkanın işini kolaylaştırır ve kuyruğu hızlandırır. Belirsiz, geniş ve gerekçesiz talepler ise reddedilir ya da uzun uzun tartışılır — ve bu tartışma doğrudan gecikmedir. ## Entegrasyonu Bir Bağımlılık Envanteri ile Başlatmak Bir entegrasyon projesine başlarken yaptığım ilk iş kod yazmak değil, bir envanter çıkarmaktır. Bu envanter, çözümün dokunacağı bütün dış sistemleri tek bir yerde listeler ve her biri için aynı soruları sorar. Bu adımı atlayan ekipler, entegrasyon gecikmesi deneyimini parça parça, her yeni bağımlılık ortaya çıktıkça yaşarlar; envanter çıkaran ekipler ise bütün resmi baştan görür ve sürprizleri en aza indirir. Bağımlılık envanterinde her sistem için şu soruları yanıtlarım: Bu sisteme neden bağlanıyoruz, hangi veriyi alıp hangi veriyi yazacağız? Sistemin sahibi kim, iç ekip mi dış tedarikçi mi? Bir API'si var mı, varsa belgeli mi? Kimlik doğrulaması nasıl çalışıyor? Hız limitleri neler? İzin verilmiş bir test ortamı var mı? Hangi veri erişim izinleri gerekiyor ve bunlar hangi onay zincirinden geçiyor? Bu soruların cevapları çoğu zaman ilk günde bilinmez; ama soruları sormak bile, nerede belirsizlik olduğunu ve dolayısıyla riskin nerede yoğunlaştığını gösterir. Envanterin asıl değeri, belirsizliği görünür kılmasıdır. Bir sistem hakkında "sahibi kim bilmiyoruz" diye bir satır yazdığınızda, o satır artık bir risktir ve yönetilebilir. Görünmeyen risk yönetilemez; görünen risk planlanabilir. Bu yüzden envanteri bir formalite değil, projenin risk haritası olarak görürüm. Bu haritayı çıkarmak, kurumsal mimarinin bütününü anlamayı gerektirir; bu bakışı kurumsal RAG rehberi ve veri akışının disipline edilmesini veri sözleşmeleri yazılarında ele alıyorum. Envanteri çıkarırken bir gerçeği de kabul etmek gerekir: liste büyüdükçe proje karmaşıklaşır. Beş sisteme bağlanan bir çözüm, tek sisteme bağlanandan beş kat değil, çok daha fazla karmaşıktır; çünkü bağımlılıklar birbirini etkiler. Bu yüzden envanter aynı zamanda bir kapsam daraltma aracıdır: "bu bağlantı gerçekten ilk sürümde şart mı, yoksa sonraya bırakılabilir mi" sorusunu sormak, entegrasyon gecikmesi deneyimini küçültmenin en güçlü kaldıraçlarından biridir. En iyi entegrasyon, hiç yapmak zorunda kalmadığınız entegrasyondur. ## Hız Limitleri ve Toplu İşleme: Mimariyi Limite Göre Kurmak Eski sistemlerin katı hız limitleri, entegrasyon gecikmesi deneyiminin teknik olarak en çok yeniden tasarım gerektiren yanıdır. Modern bir yapay zeka çözümü, saniyede çok sayıda istek göndermeye alışkındır; karşı sistem ise "dakikada şu kadar" diyorsa, çözümünüzün mimarisini bu limite göre yeniden düşünmeniz gerekir. Bu, sonradan yamalanan değil, baştan tasarlanması gereken bir kısıttır. Limitle başa çıkmanın birkaç yerleşik yöntemi vardır. Birincisi kuyruklamadır: istekleri hemen göndermek yerine bir kuyruğa alıp karşı sistemin dayanabileceği hızda salmak. İkincisi toplu işlemedir (batch): mümkünse çok sayıda küçük isteği tek bir toplu isteğe dönüştürmek. Üçüncüsü önbelleklemedir: sık istenen ve seyrek değişen veriyi bir kez alıp saklamak, böylece aynı veri için tekrar tekrar karşı sisteme gitmemek. Dördüncüsü zamanlamadır: yoğun işleri karşı sistemin boş olduğu saatlere kaydırmak. Bu yöntemlerin ortak amacı, karşı sistem beklemesini bir darboğaz olmaktan çıkarıp yönetilebilir bir akışa dönüştürmektir. Ama hepsi baştan planlanmayı gerektirir; hız limitini üretime geçerken keşfederseniz, bütün bu mimariyi kriz anında kurmak zorunda kalırsınız — ki bu, entegrasyon gecikmesi deneyiminin en pahalı senaryolarından biridir. Bu yüzden hız limitini erken öğrenmek, envanterin en kritik satırlarından biridir. Bu akış ve kuyruk mimarisini pipeline, workflow orchestration ve stream processing yazılarında daha geniş ele alıyorum. Bir saha gözlemi ekleyeyim: hız limitleri çoğu zaman belgelerde yazandan daha düşüktür. Belge "dakikada yüz istek" der ama gerçekte sistem elli istekte yavaşlamaya başlar; çünkü belge ideal koşulu, gerçek ise o anki yükü yansıtır. Bu yüzden hız limitini belgeye değil, gerçek denemeye dayanarak keşfetmek gerekir. Test ortamında yapılan bir yük denemesi, üretimde patlayacak bir darboğazı baştan gösterir. İşte test ortamının, hız limitlerini erken görmedeki rolü de burada devreye girer. ## Karşı Ekiple İletişim: Doğru Soruyu Doğru Kişiye Sormak Bu saha notu boyunca tekrarladığım bir tema var: entegrasyonu iyi yönetmek, en iyi kod yazmak değil, en iyi iletişimi kurmaktır. Karşı sistem beklemesini küçülten şey, teknik ustalık değil, doğru soruyu doğru kişiye doğru zamanda sorma disiplinidir. Bu, kulağa basit gelen ama sahada sürekli ihlal edilen bir beceridir. İletişimin ilk kuralı, muhatabı doğru bulmaktır. Büyük kurumlarda, bağlanacağınız sistemi teknik olarak bilen kişi ile o sisteme erişim iznini verebilecek kişi çoğu zaman farklıdır; ve ikisini de bulmak zaman alır. Yanlış kişiye sorulan doğru soru, günlerce dolaşıp geri döner. Bu yüzden envanteri çıkarırken her sistem için "teknik muhatap kim, izin muhatabı kim" sorusunu ayrı ayrı yanıtlamaya çalışırım. İkinci kural, soruyu net ve toplu sormaktır. Karşı ekibe her gün bir soru göndermek, her seferinde onların kuyruğuna yeniden girmek demektir; oysa ihtiyaçlarınızı tek seferde, yazılı ve gerekçeli bir listeyle iletmek, tek bir kuyruk turunda çözülmelerini sağlar. "Şu erişimi, şu amaçla, şu tarihe kadar istiyorum" biçiminde net bir talep, muhatabın işini kolaylaştırır ve karşı sistem beklemesini kısaltır. Belirsiz sorular, belirsiz ve geç cevaplar üretir. Üçüncü kural, ilişkiyi bir kerelik değil sürekli kurmaktır. Entegrasyon boyunca aynı ekiple defalarca konuşacaksınız; bu yüzden ilk temastan itibaren iyi niyetli, net ve öngörülebilir olmak, sonraki taleplerinizin daha hızlı dönmesini sağlar. Sahada gördüğüm en hızlı entegrasyonlar, en iyi araçlara sahip olanlar değil, karşı ekiple en sağlıklı ilişkiyi kuranlardı. Bu insan ve organizasyon tarafının eğitimle güçlendirilmesini kurumsal yapay zeka eğitimi nedir yazısında ele alıyorum. İletişim disiplini, entegrasyon gecikmesi deneyimini yönetmenin belki de en hafife alınan aracıdır. ## Entegrasyon Testinin Katmanları Test ortamının varlığı gerekli ama yeterli değildir; o ortamda neyi nasıl test edeceğiniz de önemlidir. Entegrasyon testi tek bir şey değil, birkaç katmandan oluşur ve her katman farklı bir gecikme kaynağını erken yakalar. Bu katmanları atlamak, entegrasyon gecikmesi deneyimini üretime taşımak demektir. İlk katman birim düzeyinde bağlantı testidir: karşı sisteme tek bir istek gönderip doğru yanıtı alabiliyor musunuz? Bu, kimlik doğrulama ve temel bağlantı sorunlarını yakalar. İkinci katman veri eşleme testidir: gerçek örnek veriyle, iki sistemin alanlarının doğru eşleşip eşleşmediğini, istisnaların doğru ele alınıp alınmadığını denemek. Bu katman, boş kayıt, biçim uyuşmazlığı ve tek-çoklu kayıt gibi istisnaları yüzeye çıkarır. Üçüncü katman uçtan uca testtir: gerçek bir kullanıcı senaryosunu baştan sona çalıştırmak. Tek tek adımlar çalışsa bile, hepsi bir araya geldiğinde beklenmeyen sorunlar çıkabilir; uçtan uca test bunları yakalar. Dördüncü katman yük testidir: karşı sistemin gerçek hacim altında nasıl davrandığını, hız limitlerinin nerede devreye girdiğini görmek. Bu katman, üretimde patlayacak darboğazları test ortamında keşfeder ve belki de en pahalı gecikmeyi önler. Bu katmanların ortak mantığı, sorunu mümkün olan en küçük ve en erken biçimde yakalamaktır. Bir bağlantı sorununu birim testte yakalarsanız beş dakikada çözersiniz; aynı sorunu üretimde yakalarsanız bir kriz olur. Bu yüzden test, entegrasyonun sonuna eklenen bir kontrol değil, entegrasyonla iç içe yürüyen bir keşif sürecidir. Testin ve üretim sonrası izlemenin disiplinini model izleme ve drift ve veri toplamanın hizmet düzeyini veri toplama SLA yazılarında ele alıyorum. Bir saha gözlemi olarak söyleyeyim: test katmanlarını atlayan hız, neredeyse her zaman sonradan daha büyük bir yavaşlamaya dönüşür. ## Sözleşme, SLA ve Dış Tedarikçi Gerçekliği Karşı sistem bir dış tedarikçinin elindeyse, entegrasyon gecikmesi deneyimine tamamen yeni bir boyut eklenir: ticari ve sözleşmesel gerçeklik. İç ekiplerle en azından aynı kurumsal önceliği paylaşırsınız; dış tedarikçiyle araya sözleşme kapsamı, hizmet düzeyi anlaşması (SLA) ve ticari öncelikler girer. Bu katmanı hesaba katmayan bir plan, dış bağımlılıklarda sürekli sürprizle karşılaşır. En sık gördüğüm sorun, ihtiyaç duyulan işin sözleşme kapsamı dışında kalmasıdır. "Küçük bir değişiklik" dediğiniz şey, tedarikçinin mevcut sözleşmesinde tanımlı olmayabilir; bu durumda önce bir kapsam görüşmesi, sonra bir teklif, sonra bir onay ve ancak ondan sonra iş başlar. Bu ticari döngü, teknik işten bağımsız olarak haftalar ekleyebilir. Bu yüzden dış tedarikçiyle çalışırken, ihtiyaç duyacağınız işin sözleşme kapsamında olup olmadığını en erken netleştirmek kritiktir. İkinci gerçeklik, SLA'nın sizin lehinize işlemeyebileceğidir. Bir tedarikçinin "beş iş günü içinde yanıt" taahhüdü, sizin acil ihtiyacınız için çok yavaş olabilir; ama sözleşme buysa, karşı sistem beklemesi bu süreyle sınırlıdır ve bunu hızlandırmak çoğu zaman mümkün değildir. Bu yüzden planınızı tedarikçinin gerçek SLA'sına göre kurmak, iyimser bir tahmine göre kurmaktan çok daha sağlıklıdır. Bulut hizmeti mi yoksa kendi altyapınız mı sorusunun bu bağımlılığa etkisini self-hosted LLM vs API karar rehberi yazısında değerlendiriyorum. Üçüncü gerçeklik, bilgi asimetrisidir. Tedarikçi kendi sistemini sizden çok daha iyi bilir; bu, sizi doğru soruyu soramama riskine açık bırakır. Bu asimetriyi azaltmanın yolu, envanter aşamasında tedarikçiden sistemin gerçek davranışını, limitlerini ve istisnalarını açıkça istemektir. Sahada öğrendiğim ders şu: dış tedarikçiyle entegrasyonda en büyük gecikme kaynağı teknik zorluk değil, ticari ve iletişimsel sürtünmedir. Bu sürtünmeyi erken ve net bir çerçeveyle azaltmak, entegrasyon gecikmesi deneyimini yönetmenin ayrılmaz bir parçasıdır. Bu ticari planlamanın bütçe tarafını kurumsal AI bütçesi planlama yazısında ele alıyorum. ## Gecikme Kaynağı × Belirti × Önleyici Aksiyon Şimdi bu saha notunun özünü tek bir yerde toplayalım. Aşağıdaki tablo, entegrasyon gecikmesi deneyimimde tekrar tekrar gördüğüm gecikme kaynaklarını, her birinin sahada nasıl belirti verdiğini ve bu gecikmeyi küçültmek için erken alınabilecek önleyici aksiyonu bir arada gösteriyor. Bu tabloyu, bir entegrasyon projesine başlarken bir kontrol listesi gibi kullanmanızı öneririm; her satır, sahada bedelini gördüğüm bir dersin damıtılmış hâlidir. Bu tablonun altını çizen tek bir örüntü var: her gecikme kaynağının önleyici aksiyonu "erken"dir. Karşı sistemi erken masaya oturt, test ortamını erken kur, veri eşlemeyi erken dene, izinleri erken iste, güvenliği erken başlat. Entegrasyon gecikmesi deneyimini yönetmenin sırrı daha hızlı kod yazmak değil, riskli işi öne almaktır. Erken keşfedilen bir sorun küçük ve ucuzdur; aynı sorun geç keşfedilirse büyük ve pahalıdır. ## Gerçekçi Planlama Önerisi Şimdiye kadar anlattığım her gecikme kaynağı, aslında tek bir kök nedene işaret ediyor: entegrasyonun projenin sonuna, "son bir hafta"ya bırakılması. Gerçekçi planlamanın özü bunu tersine çevirmektir. Entegrasyon, projenin en riskli ve en az kontrol edilebilir parçasıdır; bu yüzden sona değil, başa konmalıdır. Aşağıdaki adımlar, sahada entegrasyon gecikmesi deneyimini en çok küçülten planlama yaklaşımımı özetliyor. Bu planlama yaklaşımının kalbinde bir zihniyet değişimi var: entegrasyonu bir teknik detay değil, bir risk kalemi olarak görmek. Bir yapay zeka projesinde en büyük belirsizlik genellikle modelde değil, modelin bağlanacağı sistemlerdedir. Bu yüzden proje planını "önce model, sonra entegrasyon" diye değil, "en riskli entegrasyonu erken keşfet, model ile paralel ilerlet" diye kurmak, entegrasyon gecikmesi deneyimini kökten değiştirir. Bu bütünsel planlamayı kurumsal düzeyde yapay zeka yol haritası nedir ve bütçeleme tarafını kurumsal AI bütçesi planlama yazılarında ele alıyorum. Bir uyarı: gerçekçi planlama, "her şeyi baştan mükemmel öngör" demek değildir. Öngöremeyeceğiniz sürprizler her zaman olacak. Gerçekçi planlamanın amacı sürprizi yok etmek değil, sürprizi erkene çekmek ve küçültmektir. Erken keşfedilen bir gecikme yönetilebilir; geç keşfedilen aynı gecikme krizdir. Fark, planlamanın kalitesindedir — model kalitesinde değil. ## Entegrasyon Neden Gecikiyor? Bu saha notunun belki de en çok sorulan sorusu bu: entegrasyon neden gecikiyor? Şimdiye kadar anlattıklarımı tek bir cevapta toplayayım. Entegrasyon gecikiyor çünkü entegrasyon, kontrolünüzdeki bir işten çok, kontrolünüz dışındaki bağımlılıkların bir zinciridir. Kendi kodunuzu istediğiniz hızda yazarsınız; ama karşı sistemin müsaitliğini, test ortamının varlığını, izinlerin onayını ve güvenlik kuyruğunun hızını siz belirlemezsiniz. Bunu daha somut söyleyeyim. Entegrasyon gecikmesi deneyiminde tekrar eden neden zinciri şudur: karşı sistemin sahibi müsait olana kadar beklersiniz (karşı sistem beklemesi); denemek için izin verilmiş bir test ortamı olmadığından yavaş ve riskli ilerlersiniz; gerçek veriyle deneyince beklemediğiniz veri eşleme istisnalarıyla karşılaşırsınız; eski sistemin belgesiz API'si, eski kimlik doğrulaması ve katı hız limitleri her adımı uzatır; ve tüm bunlar bittiğinde bile güvenlik ve izin gözden geçirme kuyruğunda beklersiniz. Her biri tek başına küçük, ama üst üste binince aylara varan bir gecikme. Kritik olan şudur: bu nedenlerin hemen hepsi teknik değil örgütseldir. Yani daha iyi bir modelle, daha hızlı bir sunucuyla ya da daha yetenekli bir mühendisle çözülmezler. Bunlar iletişim, koordinasyon, önceliklendirme ve onay problemleridir. Bu yüzden entegrasyon gecikmesini gerçekten anlamak, onu bir mühendislik sorunu olarak görmeyi bırakıp bir proje yönetimi ve organizasyon sorunu olarak görmekle başlar. Bu bakış açısı, pilotta kalan projelerin neden üretime geçemediğini de açıklar; bu örüntüyü pilotta kalan projeler saha notu yazısında ayrıntılı ele alıyorum. Entegrasyonun gecikmesinin bir de gizli bir psikolojik boyutu var. Model çalıştığında ekip "işin zor kısmı bitti" hisseder ve rahatlar; entegrasyonu bir formalite sanır. Oysa saha gerçeği tersidir: model çoğu zaman kolay kısımdır, entegrasyon zor kısımdır. Bu yanlış rahatlama, entegrasyona yeterince erken ve yeterince ciddi yaklaşılmamasına yol açar — ve gecikmenin en derin kökü budur. Bu yanılgının benzerini eğitimden üretime geçişte de görüyorum; eğitimden üretime geçiş — sadece model yetmez yazısı bu "model bitince iş biter" yanılgısını daha geniş ele alır. ## Test Ortamı Neden Kritik? Bu saha notunda test ortamının önemine ayrı bir başlık daha açmam tesadüf değil; çünkü entegrasyon gecikmesi deneyiminde test ortamı yokluğu, hem doğrudan hem dolaylı olarak en çok gecikme üreten kalemdir. Test ortamının neden bu kadar kritik olduğunu üç açıdan görmek gerekir. Birincisi, entegrasyon deneme-yanılmadır ve deneme-yanılma güvenli bir yer ister. Bir isteği gönderip yanıtı görmek, bir alanı düzeltip tekrar denemek, bir istisnayı yakalayıp ele almak — bunların hepsi tekrarlı denemeler gerektirir. Bu denemeleri üretim üzerinde yapmak, gerçek müşteriyi ve gerçek veriyi her seferinde riske atmak demektir. İzin verilmiş bir test ortamı, bu döngüyü korkusuzca çalıştırmanızı sağlar; test ortamı yoksa döngü ya durur ya da her adımda onay bekler. İkincisi, test ortamı istisnaları erken görmenizi sağlar. Ama bunun için test ortamının gerçekçi olması, yani gerçek verinin istisnalarını içermesi gerekir. Boş bir test ortamı yanıltıcıdır: her şey yolunda görünür çünkü içinde sorun çıkaracak veri yoktur. Gerçek veriyi (uygun şekilde anonimleştirilmiş olarak) yansıtan bir test ortamı ise veri eşleme istisnalarını, hız limitlerini ve kimlik doğrulama sorunlarını üretime geçmeden önce yüzeye çıkarır. Bu, en pahalı gecikmeyi (üretimde patlayan sürpriz) en ucuz gecikmeye (testte yakalanan sorun) çevirir. Üçüncüsü, test ortamı ekibin özgüvenini ve hızını korur. Üretim üzerinde çalışan bir ekip, her adımda "ya bir şeyi bozarsam" korkusuyla ilerler; bu korku hızı düşürür ve gerginlik yaratır. İzole bir test ortamı, "burada hata yapsam bir şey olmaz" güvenini verir; bu güven, denemeyi hızlandırır ve dolayısıyla entegrasyonu hızlandırır. Test ortamının kurulması ve üretime güvenli geçişin disiplinini LLMOps nedir ve MLOps nedir yazılarında ele alıyorum. Test ortamı kurmak zaman ve emek ister; bu yüzden bazı ekipler "hızlı gidelim, doğrudan üretimde çalışalım" der. Sahada bu neredeyse her zaman daha yavaş çıkar. Test ortamı kurmanın maliyeti öngörülebilir ve tek seferliktir; test ortamı olmadan üretimde çalışmanın maliyeti öngörülemez ve tekrar tekrar ödenir — her risk, her bekleme, her geç keşfedilen istisna olarak. Test ortamını bir gecikme değil, gecikmeye karşı bir sigorta olarak görün. ## Entegrasyon Nasıl Planlanmalı? Üçüncü kritik soru: entegrasyon nasıl planlanmalı? Cevabı bu saha notunun boyunca örtük olarak verdim; şimdi net bir çerçeveye oturtayım. Entegrasyon planlaması, tek bir ilke etrafında döner: dış bağımlılıkları erken keşfet, erkene çek ve paralelleştir. Bu ilkeyi hayata geçiren birkaç somut karar var. İlk karar, entegrasyonu takvimin sonuna değil başına koymaktır. Geleneksel yaklaşım "önce çözümü yapalım, sonra bağlayalım" der; bu, en riskli işi en sona bırakmak demektir ve entegrasyon gecikmesi deneyiminin ana kaynağıdır. Doğru yaklaşım tersidir: en belirsiz ve en kritik entegrasyonu, projenin ilk günlerinde, model henüz olgunlaşmadan denemek. Böylece bir sorun varsa, onu düzeltmek için bütün proje süresi elinizde olur; sona bıraksaydınız, aynı sorun teslim tarihini kaçırtırdı. İkinci karar, her dış bağımlılık için bir sorumlu ve bir tampon süre tanımlamaktır. "Bu sisteme bağlanacağız" cümlesi bir plan değildir; "bu sisteme, şu tarihe kadar, şu kişinin koordinasyonuyla, şu tampon süreyle bağlanacağız" bir plandır. Karşı sistem beklemesini bir sürpriz değil, planlanmış bir kalem hâline getirmek, gecikmeyi yönetilebilir kılar. Bu bağımlılıkların önceliklendirilmesinde AI use-case önceliklendirme matrisi yazısındaki çerçeve yardımcı olur. Üçüncü karar, ilerlemeyi doğru ölçmektir. Entegrasyon aşamasında "kod ne kadar hazır" yanıltıcı bir ölçüdür; çünkü kod hazır olsa bile proje dış bağımlılıklarda bekliyor olabilir. Doğru ölçü şudur: hangi dış bağımlılık hangi aşamada — talep edildi mi, yanıt geldi mi, test edildi mi, onaylandı mı? İlerlemeyi bekleme kalemleri üzerinden izlemek, projenin gerçek durumunu gösterir ve gecikmeleri erken görünür kılar. Bu görünürlüğü üst yönetime doğru anlatmak da ayrı bir beceridir; üst yönetime yapay zeka projesi sunumu yazısı bu iletişimi ele alır. Son olarak, planlama sürekli güncellenen bir şey olmalıdır. Entegrasyon keşif dolu bir aşamadır; her yeni keşif planı değiştirir. Katı, değişmez bir plan yerine, yeni bilgi geldikçe güncellenen esnek bir plan, entegrasyon gerçekliğine çok daha uygundur. Amaç mükemmel bir ilk plan değil, hızlı öğrenip hızlı uyarlanan bir süreçtir. ## Entegrasyon Gecikmesinin Gerçek Maliyeti Entegrasyon gecikmesi deneyimini sadece "takvim kaydı" olarak görmek, maliyetini eksik anlamaktır. Gecikmenin görünen maliyeti zamandır; ama görünmeyen maliyetleri çoğu zaman daha ağırdır ve bunları hesaba katmayan bir plan, gecikmenin gerçek bedelini küçümser. Birinci görünmeyen maliyet, fırsat maliyetidir. Entegrasyonda bekleyen bir çözüm, o süre boyunca değer üretmez; sağlayacağı verimlilik, çözeceği sorun, açacağı fırsat ertelenir. Model çalışıyor olabilir, ama üretime bağlanmadığı sürece bir demodan ibarettir. İkinci maliyet, ekip moralidir: aylarca "az kaldı" denip bitmeyen bir entegrasyon, ekibin motivasyonunu ve projeye olan inancını aşındırır. Üçüncü maliyet, güven kaybıdır: gecikme uzadıkça, paydaşların projeye ve onu yürüten ekibe olan güveni azalır ve bir sonraki yapay zeka girişimi daha şüpheyle karşılanır. Dördüncü ve belki en sinsi maliyet, bağlam kaybıdır. Entegrasyon uzadıkça, projenin başında verilen kararların gerekçeleri unutulur, ekip üyeleri değişir, öncelikler kayar. Aylar önce net olan bir tasarım kararı, bugün "bunu neden böyle yapmıştık" sorusuna dönüşür. Bu bağlam erozyonu, gecikmeyi daha da büyütür; çünkü unutulan her karar yeniden tartışılır. Bu yüzden entegrasyonu hızlı bitirmek yalnızca bir takvim meselesi değil, projenin bütün bilgisini ve momentumunu korumanın da yoludur. Bu maliyetleri görünür kılmak, entegrasyona doğru önceliği vermenin en güçlü gerekçesidir. "Sadece bağlayacağız" diye küçümsenen bir aşama, aslında projenin en pahalı gecikmesini barındırabilir. Bu yüzden bir yapay zeka projesinin bütçesini ve takvimini kurarken entegrasyonu bir kalem olarak açıkça ayırmak, onu görünmez bir varsayım olmaktan çıkarır. Bu bütçeleme disiplinini kurumsal AI bütçesi planlama ve önceliklendirmeyi AI use-case önceliklendirme matrisi yazılarında ele alıyorum. Gecikmenin gerçek maliyetini kabul eden bir ekip, entegrasyona hak ettiği ciddiyetle yaklaşır — ve bu ciddiyet, entegrasyon gecikmesi deneyimini kökten küçültür. ## Saha Gözlemi: Tekrar Eden Örüntüler Bu saha notunu, farklı projelerde tekrar tekrar gördüğüm birkaç örüntüyle bağlamak istiyorum. Bunlar tek bir projeye ait değil; entegrasyon gecikmesi deneyimimin geneline yayılan, sektörden bağımsız gözlemler. Her biri, bir sonraki projenizde dikkat etmeniz gereken bir işaret niteliğinde. Birinci saha gözlemi: gecikmeyi erken deneyen ekipler küçük, geç deneyen ekipler büyük yaşar. Aynı entegrasyon sorunu — diyelim bir veri eşleme istisnası — projenin başında keşfedilirse iki saatlik bir düzeltmedir; sonunda keşfedilirse teslim tarihini kaçırtan bir krizdir. Sorunun büyüklüğü sabit değildir; ne zaman keşfedildiğine bağlı olarak büyür ya da küçülür. Bu yüzden en değerli entegrasyon becerisi, kod yazmak değil, riskli işi öne almaktır. İkinci saha gözlemi: "model bitti, gerisi kolay" hissi neredeyse her zaman yanıltıcıdır. Ekipler modelin çalıştığını görünce rahatlar ve entegrasyonu hafife alır. Oysa saha gerçeği tersidir: model çoğu zaman işin kolay yarısı, entegrasyon zor yarısıdır. Bu yanlış rahatlama, entegrasyona geç ve gevşek yaklaşmaya yol açar. Bu örüntüyü kullanıcı benimsemesi tarafında da görüyorum; teknik çözüm hazır olsa bile kullanıcının onu benimsemesi ayrı bir emek ister ve bunu kullanıcı benimsemesi saha notu yazısında ele alıyorum. Üçüncü saha gözlemi: dış bağımlılıklar her zaman tahmin ettiğinizden yavaştır. "Onlar bir günde döner" diye planlarsınız, bir hafta sürer. Bu, karşı ekibin yeteneksizliği değil, önceliklerin farklılığıdır; sizin acil işiniz, onların sıradan bir talebidir. Bu gözlemi kabul etmek, planlamayı gerçekçi kılar: dış bağımlılıklar için her zaman düşündüğünüzden fazla tampon bırakın. Dördüncü saha gözlemi: belgesizlik en pahalı gizli maliyettir. Eski sistemlerin belgesiz olması, entegrasyonu deneme-yanılmaya çevirir ve her deneme karşı sistem beklemesiyle uzar. Sistemi bilen kişiyi bulmak, çoğu zaman kod yazmaktan daha değerlidir. Bu gözlem, regüle sektörlerde onay süreçleriyle birleşince daha da belirginleşir; onay ve entegrasyonun kesiştiği yeri regüle sektör onay saha notu ve on-premise kısıtların gerçekliğini on-premise gerçekler saha notu yazılarında anlatıyorum. Beşinci saha gözlemi: entegrasyonu iyi yöneten ekiplerin ortak özelliği teknik üstünlük değil, iletişim disiplinidir. En iyi entegrasyoncular, en iyi kod yazanlar değil, doğru soruyu doğru kişiye erken soranlardır. Entegrasyon gecikmesi deneyimini küçülten şey, bir kütüphane ya da araç değil, bir alışkanlıktır: erken sor, erken dene, erken keşfet. Bu insan tarafını, dönüşüm kalıpları bağlamında dönüşüm kalıpları saha notu ve doküman hazırlığı tarafını doküman hazırlığı saha notu yazılarında tamamlıyorum. ## Kısmi Entegrasyon ve Aşamalı Devreye Alma Entegrasyon gecikmesi deneyimini küçültmenin güçlü ama az kullanılan bir yolu, entegrasyonu tek bir büyük adım olarak değil, aşamalı bir devreye alma olarak tasarlamaktır. "Ya hep ya hiç" yaklaşımı, bütün bağımlılıkların aynı anda hazır olmasını bekler; oysa gerçek dünyada bağımlılıklar farklı hızlarda hazır olur. Aşamalı yaklaşım, hazır olan parçayı beklemeden devreye alır ve geri kalanı olgunlaştıkça ekler. Bunun bir tekniği, karşı sistem hazır olmadan sahte bir uç nokta (mock) ile ilerlemektir. Karşı sistemin ne döndüreceğini biliyorsanız, o yanıtı taklit eden geçici bir bileşen kurup kendi tarafınızı geliştirmeye devam edebilirsiniz; karşı sistem hazır olduğunda sahteyi gerçeğiyle değiştirirsiniz. Böylece karşı sistem beklemesi sizin ilerlemenizi durdurmaz; iki taraf paralel olgunlaşır. Bu, entegrasyon gecikmesi deneyimini seri bir bekleme zincirinden paralel bir akışa çevirir. Aşamalı devreye almanın bir başka biçimi, entegrasyonu önce dar bir kapsamla açmaktır: tek bir kullanıcı grubu, tek bir veri türü, tek bir senaryo. Dar kapsam, hem riski küçültür hem de gerçek dünyadaki istisnaları düşük hacimde, yönetilebilir biçimde ortaya çıkarır. Sorunları küçük ölçekte görüp düzeltmek, hepsini birden büyük ölçekte yaşamaktan çok daha ucuzdur. Bu aşamalı mantığı, projelerin pilottan üretime geçişini ele aldığım pilotta kalan projeler saha notu ve yol haritası tasarımını ele aldığım yapay zeka yol haritası nedir yazılarıyla birlikte okumak faydalı olur. Aşamalı yaklaşımın gizli faydası, öğrenmeyi hızlandırmasıdır. Her aşama, bir sonraki için ders üretir; ilk dar devreye almada keşfettiğiniz bir veri eşleme istisnası, sonraki aşamaları baştan düzeltmenizi sağlar. Bu yüzden aşamalı devreye alma yalnızca riski değil, belirsizliği de azaltır. Bir saha gözlemi olarak söyleyeyim: entegrasyonu tek hamlede bitirmeye çalışan ekipler genellikle daha yavaş biter; parça parça ilerleyenler, sürekli değer üreterek daha hızlı ve daha sağlam bir sonuca ulaşır. ## Hata Senaryoları ve Geri Alınabilirlik Entegrasyon planlaması yalnızca "her şey yolunda giderse" senaryosunu değil, "bir şey ters giderse" senaryosunu da kapsamalıdır. Sahada gördüğüm gecikmelerin bir kısmı, hata anında ne yapılacağının baştan düşünülmemesinden kaynaklanır. Karşı sistem yanıt vermezse, yavaşlarsa, hatalı veri dönerse ya da yarı yolda koparsa çözümünüz ne yapacak? Bu soruların cevabı baştan tasarlanmazsa, ilk hata anında proje durur ve bir kriz yönetimi gecikmesi başlar. Sağlam bir entegrasyon, karşı sistemin kusurlu davranacağını varsayar. Bu yüzden yeniden deneme (retry) mantığı, zaman aşımı (timeout) sınırları, ve karşı sistem çöktüğünde çözümün nazikçe bozulması (graceful degradation) baştan planlanır. Karşı sistem geçici olarak erişilemez olduğunda bütün çözümün çökmesi yerine, o bölümün devre dışı kalıp gerisinin çalışmaya devam etmesi, hem kullanıcı deneyimini hem de projenin dayanıklılığını korur. Bu koruyucu katmanların mantığını guardrail nedir ve otomatik ajanlarda hata yönetimini ajan hata yönetimi ve geri alma yazılarında ele alıyorum. Geri alınabilirlik de kritik bir tasarım ilkesidir. Bir entegrasyon adımı ters giderse, sistemi güvenli bir önceki duruma döndürebilmek gerekir; özellikle karşı sisteme veri yazan entegrasyonlarda, yanlış yazılan bir kaydı geri almak baştan planlanmalıdır. Aksi hâlde bir hata, temizlenmesi günler alan bir veri kirliliğine dönüşür — ki bu, entegrasyon gecikmesi deneyiminin en sinsi biçimlerinden biridir. Güvenlik açısından, karşı sisteme yazma yetkisinin kötüye kullanılması riskini de hesaba katmak gerekir; bu tür saldırı yüzeylerini prompt injection nedir yazısında ele alıyorum. Hata senaryolarını baştan düşünmek pek çok ekibe fazladan bir yük gibi gelir; oysa sahada bunun tam tersi doğrudur. Hata anını planlamayan ekipler, o an geldiğinde panikle ve doğaçlama çözümlerle daha büyük gecikmeler yaşar; hata anını planlayan ekipler ise aynı olayı öngörülmüş, prova edilmiş bir prosedürle atlatır. Dayanıklılık bir maliyet değil, gecikmeye karşı bir yatırımdır. ## Entegrasyon Durumunu Paydaşlara Doğru Anlatmak Entegrasyon gecikmesi deneyiminin az konuşulan bir yanı, teknik değil, iletişimseldir: gecikmenin paydaşlara nasıl anlatıldığı. Bir proje entegrasyon aşamasında beklerken, üst yönetim ve iş birimleri çoğu zaman ne olup bittiğini anlamaz; "model hazırdı, neden hâlâ bitmedi" sorusu havada asılı kalır. Bu iletişim boşluğu, teknik gecikmeye bir de güven kaybı ekler. Bu boşluğu kapatmanın yolu, ilerlemeyi doğru metrikle raporlamaktır. "Kod yüzde doksan hazır" gibi bir ifade yanıltıcıdır; çünkü proje asıl olarak dış bağımlılıklarda beklemektedir. Doğru rapor, "şu bağımlılık onay kuyruğunda, şu test ediliyor, şu karşı sistem yanıtı bekliyor" biçiminde, gerçek durumu bekleme kalemleriyle gösterir. Bu şeffaflık, paydaşların gecikmeyi bir başarısızlık değil, yönetilen bir süreç olarak görmesini sağlar. Bu iletişimi üst yönetim düzeyinde üst yönetime yapay zeka projesi sunumu yazısında ele alıyorum. Paydaş iletişiminde bir başka önemli nokta, beklentiyi baştan yönetmektir. Entegrasyonun dış bağımlılıklar içerdiğini ve bu bağımlılıkların takvimi etkileyebileceğini projenin başında açıkça söylemek, sona doğru gelen sürpriz gecikmelerden çok daha az hasar yaratır. "Model kısmı bizde, entegrasyon kısmı büyük ölçüde başkalarının hızına bağlı" cümlesini erken kurmak, gerçekçi bir beklenti çerçevesi oluşturur. Bu çerçeveyi kurumsal dönüşüm bağlamında dönüşüm kalıpları saha notu yazısında tamamlıyorum. Son bir saha gözlemi: entegrasyon gecikmesini iyi yöneten ekipler, gecikmeyi gizlemez, görünür kılar. Bir gecikmeyi erken ve dürüstçe paylaşmak, onu sona saklayıp patlatmaktan her zaman daha az maliyetlidir. Paydaşlar, kötü haberi geç değil erken duymak ister; çünkü erken duyulan bir gecikme yönetilebilir, geç duyulan aynı gecikme bir güven krizidir. Entegrasyonun teknik yönetimi kadar, algısının yönetimi de bu saha notunun bir parçasıdır. ## Ders Çıkarımı Bu saha notunu, damıtabildiğim en yalın derslerle bitirmek istiyorum. Entegrasyon gecikmesi deneyimi bana defalarca aynı şeyi öğretti: gecikmenin kaynağı neredeyse hiçbir zaman düşündüğünüz yerde değildir. Model tarafına yatırdığınız emek görünür ve tatmin edicidir; ama projenizi asıl geciktiren, o modelin bağlanacağı görünmez, dağınık ve başkalarının kontrolündeki sistemlerdir. Birinci ders: entegrasyonu bir teknik detay değil, bir risk kalemi olarak gör. Projenin en büyük belirsizliği genellikle modelde değil, entegrasyondadır. O hâlde en çok dikkati, en çok belirsizliğin olduğu yere ver. Entegrasyonu "sonra hallederiz" diye ertelemek, en riskli işi en kötü zamana bırakmaktır. İkinci ders: erken keşfet. Bu saha notundaki her önleyici aksiyonun ortak kelimesi "erken"di. Karşı sistemi erken masaya oturt, test ortamını erken kur, veri eşlemeyi erken dene, izinleri erken iste, güvenliği erken başlat. Erken keşfedilen sorun küçük ve ucuz, geç keşfedilen aynı sorun büyük ve pahalıdır. Entegrasyonun altın kuralı budur. Üçüncü ders: gecikmenin çoğu örgütseldir, teknik değil. Bu yüzden çözümü de örgütseldir: iletişim, koordinasyon, önceliklendirme ve gerçekçi planlama. Daha iyi bir model ya da daha hızlı bir mühendis, karşı sistem beklemesini kısaltmaz; ama erken ve net bir talep, bir onay kuyruğunu hızlandırır. Entegrasyon gecikmesi deneyimini yönetmek, bir mühendislik becerisinden çok bir proje yönetimi becerisidir. Dördüncü ders: gerçekçi ol, ama karamsar olma. Entegrasyon gecikmeleri kaçınılmazdır; ama yönetilemez değildir. Onları önceden görebilir, erkene çekebilir ve küçültebilirsiniz. Bu saha notunun amacı sizi entegrasyondan korkutmak değil, ona hazırlıklı yakalamaktır. Hazırlıklı bir ekip, aynı gecikmeyi bir kriz olarak değil, planlanmış bir bağımlılık olarak yaşar — ve fark tam olarak buradadır. Beşinci ve son ders: entegrasyon gecikmesi deneyimi tekrar eden bir öğretmendir. Her proje, aynı örüntülerin biraz farklı bir kılıkta geri döndüğünü gösterir: karşı sistem beklemesi, test ortamı yokluğu, veri eşleme istisnaları, belgesiz eski sistemler ve onay kuyrukları. Bu tekrar, kötü bir haber değil, iyi bir haberdir; çünkü tekrar eden bir sorun öğrenilebilir ve önceden hazırlanabilir bir sorundur. Bir sonraki projenizde bu saha notundaki gecikme kaynağı × belirti × önleyici aksiyon tablosunu bir kontrol listesi gibi açıp her satırı erkenden sorarsanız, aynı gecikmeleri çok daha küçük yaşarsınız. Sahada ustalaşmak, sürprizleri yok etmek değil, onları tanıdık kılmaktır. Eğer kurumunuzda bir yapay zeka projesini üretime taşımaya hazırlanıyor ve entegrasyon aşamasındaki bu gecikmeleri baştan doğru planlamak istiyorsanız, bu saha notundaki örüntüleri sizin özel bağlamınıza uyarlayarak konuşabiliriz. Kurumunuzun sistemlerine, kısıtlarına ve önceliklerine göre bir entegrasyon ve üretime geçiş yol haritası çıkarmak için bir danışmanlık görüşmesi planlayabilir, ekiplerinizin bu disiplini kazanması için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz. ## Sık Sorulan Sorular ### Entegrasyon neden gecikiyor? Sahadaki entegrasyon gecikmesi deneyimimin özeti şudur: gecikmelerin büyük kısmı model veya kod tarafından değil, çevre sistemlere bağlanmanın örgütsel gerçeklerinden çıkar. En sık dört neden görürüm. Birincisi karşı sistem beklemesi: bağlanacağınız eski sistemin sahibi veya tedarikçisi müsait olana kadar hiçbir şey ilerlemez. İkincisi test ortamı yokluğu: güvenle deneme yapabileceğiniz izole bir ortam yoksa, her deneme üretim riski ve bekleme demektir. Üçüncüsü veri eşlemede keşfedilen istisnalar: iki sistemin aynı bilgiyi farklı tanımlaması entegrasyonun ortasında ortaya çıkar. Dördüncüsü güvenlik ve veri erişim izni gözden geçirme kuyruğudur. Bu dördü teknik değil koordinasyon problemidir; bu yüzden erken keşif ve planlama gerekir. ### Test ortamı neden kritik? Test ortamı kritiktir çünkü entegrasyonun doğası deneme-yanılmadır: bir isteği gönderirsiniz, dönen yanıtı görürsünüz, düzeltirsiniz. İzin verilmiş, üretimden izole bir test ortamı yoksa bu döngüyü ya hiç kuramaz ya da canlı sistem üzerinde risk alarak kurarsınız. Sahada test ortamı yokluğu, entegrasyon gecikmesi deneyiminin en pahalı tek kalemidir: her deneme için onay beklemek, üretimi bozma korkusuyla yavaş ilerlemek ve gerçekçi veriyle çalışamadığı için istisnaları geç görmek gecikmeyi katlar. Bu yüzden bir entegrasyon projesine başlarken sorduğum ilk sorulardan biri "kullanabileceğim bir test ortamı ve gerçekçi test verisi var mı" olur. ### Entegrasyon nasıl planlanmalı? Gerçekçi planlamanın özü, entegrasyonu projenin sonuna bırakılan bir formalite değil, en başına konan bir keşif adımı olarak görmektir. Pratikte daha ilk hafta bütün dış bağımlılıkları listeleriz (hangi sistemlere bağlanacağız, sahibi kim, API'si var mı, belgesi var mı, test ortamı var mı, hangi izinler gerekiyor). Her bağımlılık için bir sorumlu ve gerçekçi bir tampon süre tanımlarız; karşı sistem beklemesi olasılığını takvime baştan yazarız. Güvenlik ve veri erişim izni gözden geçirmesini ilk gün başlatırız çünkü bu bir kuyruktur. Ve en riskli entegrasyonu en erken deneriz, çünkü erken keşfedilen sorun küçük, geç keşfedilen sorun proje batıran bir gecikmedir. ### Veri eşleme neden bu kadar sık gecikmeye yol açar? Veri eşleme (data mapping) kağıt üzerinde iki sistemin alanlarını eşleştirmek gibi görünür ve bu yüzden hafife alınır. Gerçek gecikme detayda saklıdır: iki sistem aynı kavramı farklı adlandırır, aynı alan bir tarafta zorunlu diğer tarafta boş bırakılabilir, tarih biçimleri ve kimlik numarası formatları uyuşmaz, bir tarafta tek kayıt olan şey diğerinde çoklu kayıttır. Bu istisnalar tasarım toplantısında değil, gerçek veriyle deneme yaparken ortaya çıkar. Bu yüzden veri eşlemeyi erken ve gerçek örnek veriyle test etmek, entegrasyon gecikmesi deneyimini küçültmenin en etkili yollarından biridir. ### Eski sistem API'leri entegrasyonu nasıl yavaşlatır? Eski sistemler (legacy) entegrasyonun en zorlu tarafıdır çünkü genellikle üç sorunu bir arada taşırlar. Birincisi belgesizlik: API'nin ne döndürdüğü, hangi alanların ne anlama geldiği yazılı değildir. İkincisi eski kimlik doğrulama: modern yöntemler yerine özel, kırılgan bir oturum mekanizması olabilir. Üçüncüsü katı hız limitleri: sistem yüksek istek hacmine dayanmadığı için dakikada belirli sayıda çağrıya izin verir. Bu üçü birleşince her entegrasyon adımı karşı sistem beklemesine dönüşür; çözüm, eski sistemin sahibini erken masaya oturtmak ve gerçek davranışını erken keşfetmektir. ### Güvenlik gözden geçirmesi entegrasyonu neden geciktirir? Çünkü güvenlik ve veri erişim izni gözden geçirmesi teknik bir adım değil, bir onay kuyruğudur ve bu kuyruğun kendi hızı vardır. Bir sisteme bağlanmak, veri erişim izinleri almak, kişisel veri içeren alanlara dokunmak; bunların hepsi güvenlik, hukuk ve uyum ekiplerinin gözden geçirmesini gerektirir. Teknik iş bir günde bitse bile, gözden geçirme kuyruğu haftalar sürebilir. Öğrenilen ders, güvenlik ve izin gözden geçirmesini projenin ilk gününde, teknik işe paralel başlatmaktır. Böylece teknik iş bittiğinde onay da hazır olur, iki bekleme üst üste binmez. ## Kısaca: Entegrasyon Gecikmelerini Yönetmek Kısaca özetleyeyim: bu saha notu, bir yapay zeka projesinin en az konuşulan ama en çok takvim kaydıran aşamasına, entegrasyona odaklandı. Anlattığım entegrasyon gecikmesi deneyiminin özü şu: gecikmelerin çoğu teknik değil örgütseldir. Karşı sistem beklemesi, test ortamı yokluğu, veri eşleme istisnaları, belgesiz eski sistem API'leri, kimlik doğrulama ve hız limitleri, veri erişim izinleri ve güvenlik gözden geçirme kuyruğu — bunların hepsi kodla değil, erken keşif, koordinasyon ve gerçekçi planlama ile yönetilir. En önemli mesaj tek bir kelimede toplanıyor: erken. Karşı sistemi erken masaya oturt, test ortamını erken kur, veri eşlemeyi erken dene, izinleri erken iste, güvenliği erken başlat. Erken keşfedilen bir gecikme küçük ve ucuzdur; geç keşfedilen aynı gecikme büyük ve pahalıdır. Entegrasyonu son haftaya değil, projenin başına bir keşif ve risk yönetimi adımı olarak koymak, entegrasyon gecikmesi deneyimini kökten değiştirir. Ve son bir saha gözlemi: entegrasyonu iyi yöneten ekiplerin sırrı, teknik üstünlük değil, iletişim disiplinidir. En iyi entegrasyoncular en iyi kod yazanlar değil, doğru soruyu doğru kişiye en erken soranlardır. Kurumunuzun sistemlerine ve kısıtlarına göre bir entegrasyon ve üretime geçiş yol haritası çıkarmak için bir danışmanlık görüşmesi planlayabilir, ekiplerinizin bu disiplini kazanması için kurumsal eğitim seçeneklerini değerlendirebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.