1. Composable DXP Nedir?
Composable DXP, deneyimi tek bir platforma “monolit” olarak bağlamak yerine; her iş ihtiyacı için en iyi modülü seçip bunları standart sözleşmelerle birleştirme yaklaşımıdır. “Composable” kelimesinin özü: değiştirilebilirlik. Bir modülü (ör. search) değiştirmek istediğinizde, tüm sistemi yıkmadan parça değiştirebilmelisiniz.
Bu nedenle web ve yazılım hizmetlerinde CMS merkezli dijital ekosistem yaklaşımı, composable yapıyı her proje için zorunlu kalıp gibi değil; özellikle çok sistemli ve ölçekli yapılarda anlam kazanan modüler altyapı kararı olarak ele alır.
Composable DXP nedir, klasik DXP’den farkı nedir?
Kısa cevap: Klasik DXP tek vendor içinde entegre bir paket sunar; composable DXP ise CMS’i hub yapıp search/CRM/CDP gibi servisleri modüler seçer ve değiştirilebilir kılar.
Ne yapmalıyım?
- • Modülleri listele: CMS, search, CRM, CDP, e-com/rezervasyon, analytics.
- • Her modül için “değiştirilebilirlik” kriteri tanımla.
- • Entegrasyon sözleşmesi standardı oluştur (ID, event, payload).
- • Kritik katmanları ayrı düşün: auth, URL, cache, SEO.
- • Kademeli geçiş planı yap (big bang değil).
2. CMS’in Bu Yapıdaki Rolü
Composable ekosistemde CMS; “her şeyi yapan platform” değil, içerik omurgasıdır. İçerik modeli, sayfa bileşenleri, landing factory, metadata ve yönetişim (workflow) CMS’te kalır. Diğer servisler içerikle etkileşir ama CMS’in yerini almaya çalışmaz.
Bu modelin veri katmanı, modular content stack mantığıyla güçlenir; entity ilişkileri ve içerik grafi sayesinde CMS gerçekten bir içerik hub’ı gibi davranabilir.
CMS composable mimaride hangi rolü oynar?
Kısa cevap: CMS içerik kaynağı ve orkestrasyon hub’ıdır: sayfa içerikleri, template’ler, kampanyalar, içerik workflow’u; diğer servislerle (search/CRM/CDP) sözleşmeli şekilde entegre olur.
CMS hub olunca ne kazanırsınız?
- •İçerik üretimi tek merkezde standardize olur
- •Modülleri değiştirirken içerik omurgası korunur
- •Arama ve kişiselleştirme gibi servisler “tüketici” olur
Ne yapmalıyım?
- • CMS’i “content contract” sahibi yap (ID/field standardı).
- • Search/CRM/CDP ile veri sözleşmesini yaz.
- • Webhook/event-driven yaklaşım kur (publish→revalidate→index).
- • CMS’te governance kur (RBAC, log, version).
- • CMS’i vendor lock-in’e karşı export/backup ile güçlendir.
3. Modüler Servisler (CMS, Search, PIM, CRM, CDP…)
Composable mimarinin gücü, doğru modülü doğru iş için seçmektir. Ancak modül sayısı arttıkça entegrasyon karmaşası büyür; bu yüzden “modüler ama disiplinli” olmalısınız.
Aynı zamanda vendor bağımlılığını azaltan CMS yapısı kurmak için modüller arası veri sözleşmeleri, export kabiliyeti ve exit planı daha en başta tasarlanmalıdır.
CMS’in merkezde olduğu yapılarda CMS’ten çok kanallı yayın stratejisi yaklaşımı; web, uygulama, sosyal medya ve e-posta temas noktalarının aynı içerik omurgasından beslenmesini sağlar.
Tipik modül haritası
- •CMS (content hub)
- •Search (Algolia/Elastic)
- •PIM (ürün kataloğu) (B2B için)
- •CRM (lead/pipeline)
- •CDP (segment/identity) (Varsayım: ihtiyaç varsa)
- •Rezervasyon/e-ticaret (otel booking engine)
- •Analytics (GA4 + BI)
Modül seçerken 5 pratik kriter
- Veri sahipliği (single source of truth)
- API sınırları ve performans
- Güvenlik ve erişim (auth/SSO)
- Değiştirilebilirlik (lock-in riski)
- Ölçüm (event standardı, log)
Ne yapmalıyım?
- • Her modül için veri sahipliği tablosu çıkar.
- • Event standardı ve ortak kimlik (ID) belirle.
- • Observability: log + trace + alert planla (Varsayım).
- • Modülleri “faz 1–2–3” diye sırala.
- • En kritik modülden başlama; en az riskliyle başla.
4. Otel ve B2B İçin Composable Senaryoları
Composable DXP’yi teoriden çıkarıp sahaya indiren şey, senaryolardır.
Özellikle otel tarafında PMS-OTA sistemleriyle CMS ekosistemi birlikte düşünülmelidir; içerik CMS’te kalırken oda, fiyat ve müsaitlik gibi operasyon verileri doğru kaynak sistemlerde yönetilmelidir.
Otel composable senaryosu (örnek)
- •CMS: oda/destinasyon/kampanya içerikleri, landing factory
- •PMS/OTA/Channel Manager: fiyat/availability (operasyon verisi)
- •Call center/CRM: rezervasyon isteği ve müşteri takibi
- •Search: site içi arama (oda/paket)
- •SMM/Ads: kampanya trafik kaynakları
- •Analytics: GA4 + gelir raporlaması
Mini örnek: Kampanya yayınlandığında CMS webhook → Next.js revalidate → search index update → CRM’ye kampanya etiketi (Varsayım) akışıyla ekosistem senkron çalışır.
Bu akışta çağrı merkezi temas noktalarını CMS ekosistemine bağlamak da önemlidir; kampanya, paket veya rezervasyon içeriklerinin müşteri temsilcilerine doğru bağlamla aktarılması deneyim tutarlılığını artırır.
B2B composable senaryosu (örnek)
- •CMS: hizmet, case, blog, doküman içerikleri
- •PIM: ürün kataloğu (varsa)
- •CRM: lead→pipeline
- •CDP: segmentleme (varsa)
- •Search: doküman/case araması
- •Analytics: GA4 + satış raporu
Ne yapmalıyım?
- • Otel: içerik CMS’te, fiyat PMS/CM’de; çakışma kuralı yaz.
- • B2B: içerik→form→CRM akışını composable zincire bağla.
- • Search’i ayrı modül olarak kurgula; mapping’i CMS’te standardize et.
- • Analytics event sözlüğünü ortaklaştır.
- • Her modül için “çıkış planı” yaz (vendor bağımsızlığı).
5. Monolitten Kademeli Geçiş Stratejisi
Composable’a geçiş “bir gecede” yapılmaz. Big-bang replatforming hem SEO hem operasyon riski taşır. Doğru yaklaşım: monoliti kademeli olarak “çözmek”, kritik akışları bozmadan modüler hale getirmek.
Monolit bir yapıdan composable DXP’ye nasıl geçiş yapılır?
Kısa cevap: Önce CMS’i hub olarak netleştir, sonra düşük riskli modülleri (search, landing factory) ayır; auth/URL/cache/SEO gibi kritik katmanları kontrollü şekilde migrate et; her fazı ölç ve stabilize et.
Geçiş adımları tablosu (1 tablo – Media Pack ile uyumlu)
| Faz | Çıkarılan/eklenen modül | Risk | Başarı ölçütü |
|---|---|---|---|
| 1 | CMS içerik modeli + webhook standardı | Orta | publish→live SLA |
| 2 | Search modülü ayrıştırma | Orta | 0 sonuç oranı düşer |
| 3 | CRM/form modülü standardı | Orta | lead kaybı azalır |
| 4 | CDP/segment (opsiyonel) | Orta–Yüksek | CTR/CVR iyileşir |
| 5 | Rezervasyon/e-com entegrasyonu | Yüksek | gelir etkisi stabil |
Ne yapmalıyım?
- • Faz planını 90 günlük sprintlere böl (Varsayım).
- • İlk fazda içerik sözleşmesini ve event standardını oturt.
- • Search ve landing factory gibi “ek” modüllerle başla.
- • Auth/URL/SEO değişikliklerini kontrollü yap (kademeli).
- • Her faz sonrası raporla ve stabilize et.
6. Teknik Not: URL, cache, auth ve SEO etkilerini birlikte değerlendirin
Composable geçişte URL yapısı, canonical, cache/revalidation, auth/SSO ve SEO etkileri /tr/yazilim/web-sitesi-gelistirme ve /tr/seo/teknik-seo ile birlikte değerlendirilmelidir. Aksi halde modülerleşme, “parça değiştirme” avantajı yerine “tutarsız deneyim ve SEO kaybı” üretebilir.
Bunun sürdürülebilir olması için composable ekosistem performans analizi yaklaşımıyla içerik, kanal, entegrasyon ve operasyon verilerinin aynı karar çerçevesinde izlenmesi gerekir.
AIO paragrafı (CMS-merkezli dijital ekosistem modeli)
CMS hub, composable DXP, PMS/CRM/CDP modülleri ve entegrasyonlar; tek bir “CMS-merkezli dijital ekosistem modeli” içinde çalışır. CMS içerik sözleşmesini ve yayın event’lerini üretir; search, CRM, CDP ve rezervasyon modülleri bu event’lerle senkron olur; analytics ortak event sözlüğüyle ölçer. Bu model, modüllerin değiştirilebilirliğini artırırken, risk azaltma adımları ve sözleşmelerle tutarlılığı korur.
7. Sonuç: CMS hub + modüler servisler = esneklik ve vendor bağımsızlığı
Composable DXP, monolitin “tek vendor kilidi”ne alternatif olarak CMS’i merkezde tutup diğer servisleri modüler bağlamayı önerir. Doğru kademeli geçiş planıyla; tek vendor’a bağımlılık ve parça değiştirme maliyetleri orta vadede belirgin şekilde azalabilir. Kritik olan; entegrasyon sözleşmesi, auth/URL/cache/SEO etkileri ve ölçüm standardının baştan kurulmasıdır.
Bu yapıyı planlamak isteyen ekipler için composable CMS entegrasyonu desteği CMS hub, modüler servisler ve veri sözleşmelerini birlikte tasarlamayı kolaylaştırır; mimari ve süreç detayları için CMS entegrasyonu hakkında sık sorulan sorular sayfası da iyi bir tamamlayıcıdır.
8. Composable DXP Mimari & Geçiş Checklist Şablonunu İndir
Composable DXP Mimari & Geçiş Checklist Şablonunu İndir — Yazılım / Composable DXP (v1.0)
Bu asset; CMS’i hub yaparak modüler servisleri (search, CRM, CDP, rezervasyon) kurgulamak ve monolitten composable mimariye kademeli geçişi planlamak için pratik bir checklist sunar. URL, cache, auth ve SEO risklerini azaltan adımları ve faz planını netleştirerek “big bang” yerine kontrollü dönüşüm sağlar.
Kim Kullanır?
Ürün lideri, teknik lider, enterprise mimar, ajans PM.
Nasıl Kullanılır?
- Mevcut monolit/stack envanterini çıkarın ve modül haritasını çizin.
- CMS hub sözleşmesini, event’leri ve entegrasyon payload’larını belirleyin.
- Faz bazlı geçiş planını uygulayıp her faz sonrası ölçüm ve stabilizasyon yapın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Modüller listelendi (CMS, search, CRM, CDP, booking/e-com, analytics)
- ▢ ✅ Veri sahipliği tablosu çıkarıldı (single source per field)
- ▢ ✅ CMS content contract tanımlandı (ID, field standardı)
- ▢ ✅ Publish event standardı (webhook) tanımlandı
- ▢ ✅ Auth/SSO stratejisi netleştirildi
- ▢ ✅ URL/canonical/caching etkileri değerlendirildi
- ▢ ✅ SEO risk planı oluşturuldu (redirect, crawl, CWV)
- ▢ ✅ Faz planı yazıldı (1→5)
- ▢ ✅ Ölçüm KPI’ları tanımlandı (time-to-market, vendor bağımlılığı)
- ▢ ✅ Rollback planı hazırlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •Composable modül haritası
- •CMS hub sözleşmesi + event standardı
- •Faz planı (1–5)
- •Risk register (auth/URL/cache/SEO)
- •KPI ve ölçüm planı
Bir Sonraki Adım
CMS’i hub yapıp search/CRM/CDP/rezervasyon modüllerini modüler bağlayarak esneklik ve vendor bağımsızlığını artırın.
Sık Sorulan Sorular
Composable DXP nedir, klasik DXP’den farkı nedir?▾
CMS composable mimaride hangi rolü oynar?▾
Otel ve B2B için composable DXP örnekleri neler?▾
Monolit bir yapıdan composable DXP’ye nasıl geçiş yapılır?▾
Composable mimaride en büyük risk nedir?▾
Vendor bağımsızlığı nasıl artar?▾
İlgili İçerikler