Vendor lock‑in; çoğu ekipte ya hiç konuşulmaz ya da “her şey açık kaynak olsun” refleksiyle ele alınır. Sahada ikisi de iyi sonuç vermez.
Gerçek daha dengeli: Bazı vendor’lar hız kazandırır, bazıları güvenlik/uyumluluk sağlar. Sorun vendor kullanmak değil; çıkış maliyetini bilmemek ve operasyonel kontrol noktalarını kurmamak.
“Exit plan” ne demek? (benim tanımım)
Exit plan şunların birlikte cevaplanmasıdır:
- Bu sistemi 6 ay içinde taşımam gerekirse, en büyük teknik engel ne?
- Operasyon tarafında, vendor giderse hangi runbook’lar çöker?
- Veri ve kimlik tarafında, hangi noktada geri dönüşsüz hale geliyorum?
Kısaca: “Bir gün ayrılabilir miyiz?” değil; “ayrılmamız gerekirse kaç haftada, hangi riskle ayrılırız?”
Lock‑in’i büyüten 5 klasik hata
- Veriyi vendor formatında saklamak (export test edilmemiş)
- Gözlemlenebilirliği vendor’a bağlamak (log/metric taşınabilir değil)
- Kimlik ve yetki modelini tek platforma gömmek (IAM portability yok)
- Operasyonu vendor arayüzüne bağımlı yapmak (CLI/API yok, IaC yok)
- Sözleşmede çıkış maddelerini zayıf bırakmak (egress, SLA, support)
Teknik çıkış stratejisi: “taşınabilir katmanlar”
Benim pratikte önerdiğim 4 katman:
1) Kimlik sınırı
- IdP (SSO) mümkünse kurum kontrolünde olsun
- Yetki modelini “role” bazında standardize et
- Audit log’ları kurumda sakla
2) Veri sınırı
- Export formatı: açık ve otomatik (parquet/csv/json gibi)
- RPO/RTO hedeflerine göre “taşıma penceresi” çıkar
- Düzenli export test: “dosyayı aldım” değil, “geri yükledim” testi
3) Operasyon sınırı
- IaC ile kurulum/konfig (terraform/opentofu vb.)
- Runbook’lar vendor UI’ya değil, API/CLI’ya dayanmalı
- “Break‑glass” ve incident akışı kurum tarafından yönetilmeli
4) Gözlemlenebilirlik sınırı
- Telemetry pipeline vendor’a gömülmesin (OTel collector gibi bir kontrol düzlemi)
- Alarm ve dashboard’lar taşınabilir bir modelde tanımlansın
Operasyonel sözleşme: “teknik ops maddeleri”
Vendor ile sözleşmede (veya ek protokolde) ben şu başlıkları netleştirmeyi severim:
- Egress maliyeti: veriyi dışarı almak “cezalı” olmamalı
- Export SLA: export API/iş akışı stabil mi?
- Support: incident anında hangi kanaldan, hangi sürede destek?
- Audit log erişimi: loglar kimde, ne kadar tutuluyor?
- Değişiklik bildirimi: breaking change’ler nasıl duyuruluyor?
Bu maddeler, “teknik tasarım” kadar önemlidir; çünkü riskin yarısı sözleşmededir.
Liderlik tarafı: exit planı nasıl yaşatırsın?
Benim kullandığım operasyon ritmi:
- Çeyreklik “risk review”: vendor bağımlılık haritası + aksiyonlar
- 6 ayda bir “export/restore” mini tatbikat
- Büyük vendor kararlarında “exit plan check” zorunluluğu
Sonuç
Vendor lock‑in; doğru yönetildiğinde bir “kabus” değil, bilinçli bir takas (trade‑off) olur. Exit planı; kimlik/veri/operasyon/gözlemlenebilirlik sınırlarını doğru çizip, sözleşme maddelerini operasyon gerçekliğine bağladığında çalışır. En kritik fark ise tatbikat: test edilmemiş exit plan yok hükmündedir.