SAP Spartacus Nedir, Neden Önemlidir?

Spartacus, SAP Commerce Cloud için geliştirilen açık kaynaklı, Angular tabanlı bir mağaza ön yüzüdür. Bugün Composable Storefront adıyla anılıyor.

Kritik nokta şu: Spartacus bir e-ticaret platformu değildir. Katalog, fiyatlandırma, sipariş ve stok mantığı SAP Commerce Cloud tarafında durmaya devam eder. Spartacus yalnızca müşterinin gördüğü katmanı üstlenir ve arka uçla arayüzler üzerinden konuşur.

Bu ayrım bir teknik detay gibi görünür ama satın alma kararını doğrudan etkiler: Spartacus'a geçmek platform değiştirmek değildir, platformun üstündeki deneyimi ayrıştırmaktır. SAP Hybris'in ne olduğunu ve isminin nasıl değiştiğini ayrı bir yazıda anlattık.

Klasik kurulumda mağazanın ön yüzü platformun içinde yaşardı. JSP tabanlı bu yapıda görünen katman ile iş mantığı iç içeydi.

Bunun pratikte üç sonucu vardı. Küçük bir tasarım değişikliği bile platforma dokunmayı gerektiriyordu. Ön yüz geliştiricisinin platform bilgisi olması bekleniyordu, bu da ekip kurmayı zorlaştırıyordu. Ve kampanya dönemlerinde arayüzü hızlıca değiştirmek, sürüm döngüsüne bağlı olduğu için yavaş ilerliyordu.

Spartacus bu üç sorunu tek bir kararla çözmeye çalışır: ön yüzü ayrı bir uygulama haline getirmek.

"Başsız" ifadesi, sistemin gövdesinin (iş mantığı ve veri) baştan (kullanıcının gördüğü arayüz) ayrılması anlamına gelir.

Ayrıldıklarında ikisi arayüzler üzerinden konuşur. Arka uç "bu ürünün fiyatı şu, stoğu bu" der; ön yüz bunu nasıl göstereceğine kendi karar verir. Aynı arka uç birden fazla ön yüzü besleyebilir: web mağazası, mobil uygulama, bayi portalı ya da mağaza içi ekran.

Bunun getirdiği asıl kazanç hız değil, bağımsızlıktır. İki katman ayrı ayrı geliştirilebilir, ayrı ayrı yayınlanabilir ve ayrı ekipler tarafından sahiplenilebilir.

Getirdiği maliyet ise genellikle yeterince konuşulmaz: artık bakılacak iki uygulama vardır. Sürüm uyumu, arayüz sözleşmeleri ve iki tarafın birlikte test edilmesi yeni bir iş kalemidir.

• Barınma yeri. Klasik ön yüz platformun içinde çalışır; Spartacus ayrı bir uygulamadır.
• Değişiklik hızı. Tasarım ve kampanya değişiklikleri arka uçtan bağımsız ilerleyebilir.
• Ekip yapısı. Ön yüz tarafında Angular bilen bir geliştirici çalışabilir; platform uzmanlığı şart değildir.
• Yükseltme davranışı. Platform yükseltmeleri ile ön yüz yükseltmeleri ayrışır; bu hem kolaylık hem de takip edilmesi gereken ikinci bir takvim demektir.
• Çoklu kanal. Aynı arka uç, farklı temas noktalarını besleyebilir.

Uygun olduğu durum: SAP Commerce Cloud zaten kullanılıyor, arayüzde sık değişiklik ihtiyacı var, marka deneyimi standart mağaza şablonunun ötesine geçmek istiyor ve kurum içinde ya da ajans tarafında Angular tarafını sahiplenecek bir ekip var.

Uygun olmadığı durum: Mağaza büyük ölçüde standart akışlarla çalışıyor, arayüz nadiren değişiyor ve iki ayrı uygulamayı bakımda tutacak kapasite yoksa. Böyle bir durumda başsız mimarinin vaadi karşılıksız kalır, geriye yalnız ek karmaşıklık kalır.

Karar verirken sorulacak asıl soru teknoloji değil kapasite sorusudur: bu ön yüzü kim, hangi sıklıkta güncelleyecek? Cevabı olmayan bir geçiş, birkaç ay sonra dokunulmayan ikinci bir uygulama üretir.

Geçiş genellikle tek seferde değil, aşamalı yapılır. Planlamada netleşmesi gereken başlıklar şunlar:

1. Kapsam. Tüm mağaza mı, yoksa önce belirli akışlar mı taşınacak? Ürün listeleme ve detay sayfalarıyla başlayıp ödeme akışını sonraya bırakmak yaygın bir yaklaşımdır.
2. Arama motoru görünürlüğü. Tek sayfa uygulamalarında içeriğin taranabilir biçimde sunulması ayrı bir kurgu gerektirir. Sunucu tarafı render'ın nasıl çalışacağı, geçiş planının teknik olarak en kritik maddesidir.
3. URL yapısı. Adresler değişiyorsa yönlendirme haritası geçiş öncesinde çıkarılmalıdır; yayın haftasında değil.
4. Özelleştirme envanteri. Klasik ön yüzde yıllar içinde biriken özel geliştirmelerin hangisinin gerçekten kullanıldığı listelenmelidir. Bu liste çoğu zaman beklenenden kısadır ve kapsamı belirgin biçimde küçültür.
5. Ekip ve sahiplik. Yayın sonrası ön yüzü kimin güncelleyeceği yazılı olmalıdır.
6. Ölçüm. Geçiş öncesi mevcut performans ve dönüşüm değerleri kaydedilmelidir; aksi halde geçişin işe yarayıp yaramadığı tartışma konusu olur.

Bu maddelerin hiçbiri teknolojiyle ilgili değil; hepsi kapsam ve sorumlulukla ilgili. Geçişlerin zorlandığı yer de genellikle burasıdır.

Spartacus açık kaynaklıdır. Bu iki şey sağlar: kaynak koda bakabilirsiniz ve gerektiğinde davranışı kendi ihtiyacınıza göre genişletebilirsiniz.

Pratik faydası dokümantasyon ve topluluk erişimidir. Karşılaştığınız bir sorunun daha önce birileri tarafından yaşanmış ve yazılmış olma ihtimali, kapalı bir sisteme göre yüksektir.

Ancak açık kaynak "bedava" demek değildir. Lisans maliyeti olmaması, geliştirme, yükseltme ve bakım maliyetini ortadan kaldırmaz. Toplam sahip olma maliyetini hesaplarken bu kalem ayrıca yazılmalıdır.

Karar teknoloji seçimiyle değil envanterle başlar: bugün ön yüzde hangi özelleştirmeler var, hangileri gerçekten kullanılıyor, arayüzde yılda kaç değişiklik yapılıyor ve bunları kim yapıyor?

Bu dört sorunun cevabı, geçişin gerekli olup olmadığını çoğu zaman teknik bir karşılaştırmadan daha net gösterir. Arayüzde yılda birkaç değişiklik yapan ve bunu da dış kaynakla yürüten bir kurum için başsız mimarinin getirisi sınırlı kalır.

Bigfil bu tarafta klasik Accelerator altyapısı ve JSP tabanlı ön yüz üzerinde çalışır; Composable Storefront (Spartacus) tarafında referans projemiz yok. Teslim ettiğimiz işleri SAP Commerce Cloud hizmet sayfamızda anlattık.