Andreas Mautz

Der Mensch hinter dem CV

(der offensichtlich kein Designer ist)

Persönliche Motivation & Werte

Was macht mich aus?

Persönliche Werte

• Meine Familie
• Gesundheit und Fitness
• Wissen und Wissensvermittlung
• Wasser, Papier und Vinyl

Berufliche Werte

Ich mache komplexe Architektur-Entscheidungen durch einfache Analogien verständlich

Was macht mich aus?

• ✅ Am Puls der Zeit UND vorausschauend
• 🎯 Nachhaltig, Wartbarkeit UND Performance
• 🔄 Visionär für Entwickler UND verständlich für Entscheider

Kontinuierliche Verbesserung

(auch durch Fehler)

Galileo & Höhle der Löwen Desaster

Long Story short:

• Kunden-Shops mit TV-Auftritten
• Zu späte Infos ans Team
• Keine skalierbaren Systeme

Sofortige Ausfälle bei Sendestart

Mein (persönlicher) größter Fail

Long Story short:

• KPI-Observability Modul für Magento2
• Performance-Killer durch DB-Locks
• Lösung macht es schlimmer

Problem: Bewegungsdaten in Shop-DB statt Prometheus/Grafana

Das Learning: "Sometimes the obvious solution is obvious for a reason"

Also macht man es gut - oder halt noch einmal

Was ist mir in der Zukunft wichtig?

Langfristige Vision mit kurzfristigen Erfolgen verbinden

• ⚖️ Technische Exzellenz & Business Value
• 💪 Teamarbeit & Kommunikation
• 🧠 Kontinuierliches Lernen & Innovation

Warum sind Weinfreunde und ZooRoyal für mich spannend?

• 👩‍🏫 Können & Motivation
• ☠️ Legacy & Innovation
• 💣 Technische Schulden & schnelllebieger Markt
• ⏰ Time-to-Market & Wartbarkeit, Gründlichkeit und Testbarkeit
• 💶 Umsatz & Investitionen

Warum dieser Wechsel?

Von CTO zu Architekt:

"Von allem ein bisschen zu (m)einer Sache richtig"

Warum dieser Wechsel?

Was mich erfüllt:

• 💡 Visionen kreieren und umsetzen
• 👥 Mit kreativen, motivierten Teams arbeiten
• 🎯 Ergebnisse sehen und messbar verbessern

Meine Wunschliste für weinfreunde.de & zooroyal.de

Vision: Moderne, skalierbare, nutzbare und schnelle eCommerce-Architekturen gestalten und verbessern

Ziel: Performante, wartbare Systeme & nachhaltige Wissensweitergabe in einem motivierten Team

Architektur entsteht bei mir nicht direkt am Whiteboard, sondern erstmal beim Kaffee (ToDo)

Reflexion: Rolle als IT-Architekt

• Technische Vision entwickeln
• Entscheidungsunterstützung
• Team Enablement
• Qualitätssicherung

Technische Vision:

Langfristige Architektur-Roadmap entwickeln

Ermöglicht Observability, ist nachhaltig, verständlich und performant

Entscheidungsunterstützung:

Technische Trade-offs bewerten

Nach oben und unten Fortschritt verständlich "verkaufen"

Team-Enablement:

Entwickler:innen befähigen und coachen

Ständige Weiterentwicklung als Motor des Fortschritts

Qualitätssicherung:

Architektur-Compliance sicherstellen

Messbare Vektoren bei Performance, Stabilität und Testing

Dokumentation als "bildende" Notwendigkeit

Teamsetup ↔ Systemlandschaft ↔ Business Case

Conway's Law in der Praxis

• Microservices & autonome Teams
• Kommunikationswege = Service-Grenzen

Mein Architektur-Ansatz

• Team-orientiert
• Business-getrieben
• Evolutionär

Case: RePlatforming

Architektur-Entscheidung am Beispiel des gegebenen Zielbildes

Disclaimer

• Nur Zielbild als Ausgang
• Konzern(politik) nicht berücksichtigt
• Technische Fähigkeiten der Teams unbekannt

Der 1. "Elefant" im Raum

Der 2. "Elefant" im Raum

Analyse-Struktur

• Problemstellung
• Alternativen
• Bewertungskriterien
• Vergleichsmatrix
• Empfehlung

Problemstellung

Gewählter Aspekt: API Gateway vs. Service Mesh

Microservices-Kommunikation zwischen CommerceTools und den umliegenden Services

Problemstellung

Die Zielarchitektur zeigt eine komplexe Microservices-Landschaft mit:

• CommerceTools als zentrale eCommerce-Plattform
• Externe Services (Algolia, PayPal, Klarna...)
• Interne Services (Loyalty Cloud, Marketing Cloud...)
• Frontend-Services (Frontastic, WordPress...)

Alternative 1: API Gateway Pattern

                	
Frontend → API Gateway → Backend Services
    ↓           ↓              ↓
Frontastic → Gateway → CommerceTools
							      		 ↓
							Microservice Stack
                 				 ↓ → Algolia
                 				 ↓ → PayPal/Klarna
                 				 ↓ → Loyalty Cloud
             		
         		

Alternative 1: API Gateway Pattern

Vorteile

• Zentrale Kontrolle: Single Point of Control für alle API-Calls
• Einfache Implementierung: Bewährte Patterns, viele Tools verfügbar
• Klare Verantwortlichkeiten: Gateway handled Auth, Rate Limiting, Monitoring
• Entwickler-freundlich: Einfache Client-Integration

Alternative 1: API Gateway Pattern

Nachteile

• Single Point of Failure: Gateway-Ausfall betrifft alle Services
• Latenz: Zusätzlicher Hop für jeden Request
• Skalierungs-Bottleneck: Gateway muss für Peak-Load dimensioniert werden
• Vendor Lock-in: Abhängigkeit vom Gateway-Provider

Alternative 2: Service Mesh Pattern

                	
CommerceTools ←→ Envoy Proxy ←→ Algolia
       ↓              ↓              ↓
Loyalty Cloud ←→ Envoy Proxy ←→ Marketing Cloud
       ↓              ↓              ↓
Snowflake     ←→ Envoy Proxy ←→ CitrusAds
       ↓              ↓              ↓
Channel Pilot ←→ Envoy Proxy ←→ Emarsys
             		
         		

Alternative 2: Service Mesh Pattern

Vorteile

• Dezentrale Resilienz: Kein Single Point of Failure
• Bessere Performance: Direkte Service-zu-Service-Kommunikation
• Granulare Kontrolle: Per-Service Policies möglich
• Observability: Detaillierte Metrics und Tracing

Alternative 2: Service Mesh Pattern

Nachteile

• Komplexität: Steep Learning Curve, komplexe Debugging
• Overhead: Sidecar-Proxies verbrauchen Ressourcen
• Operational Burden: Zusätzliche Infrastruktur-Komponenten
• Team-Skills: Erfordert spezialisiertes Know-how

Alternative 3: Hybrid-Ansatz

                	
External Services → API Gateway → Internal Services with Mesh
      ↓                 ↓                    ↓
Algolia         Gateway handles:    CommerceTools ←→ Mesh
PayPal          - Authentication    Loyalty Cloud ←→ Mesh
Klarna          - Rate Limiting     Marketing Cloud ←→ Mesh
Frontastic      - SSL Termination   Snowflake ←→ Mesh
             		
         		

Alternative 3: Hybrid-Ansatz

Vorteile

• Best of Both Worlds: Gateway für externe, Mesh für interne Services
• Schrittweise Migration: Evolutionäre Einführung möglich
• Flexibilität: Unterschiedliche Patterns für verschiedene Use Cases

Alternative 3: Hybrid-Ansatz

Nachteile

• Doppelte Komplexität: Zwei Systeme zu managen
• Inkonsistente Patterns: Entwickler müssen beide Ansätze verstehen

Bewertungsmatrix (angenommen)

Meine Empfehlung: API Gateway

Begründung:

Für zooroyal.de empfehle ich den API Gateway-Ansatz mit geplanter Evolution zum Service Mesh.

Meine Empfehlung: API Gateway

Warum API Gateway first?

• Team-Readiness: Bestehende Skills im Team
• Time-to-Market: Schnelle Implementierung der Shopware-Migration
• Risiko-Minimierung: Bewährte Patterns, weniger Unbekannte
• Stufenweise Komplexität: Fokus auf Business-Features, nicht Infrastruktur

Meine Empfehlung: API Gateway

Evolution Path (angenommene 24-36 Monate):

• Phase 1: API Gateway für alle Services
• Phase 2: Service Mesh für interne Services
• Phase 3: Hybrid-Betrieb für optimale Performance

Methodik: Wie ich zu dieser Empfehlung komme

1. Stakeholder-Analyse

• Entwickler: Bevorzugen bekannte Patterns
• Operations: Wollen bewährte, supportbare Technologien
• Business: Brauchen schnelle Shopware-Migration

Methodik: Wie ich zu dieser Empfehlung komme

2. Constraint-Mapping

• Zeit: 6-12 Monate für Migration
• Budget: Begrenzte Ressourcen für Infrastruktur-Experimente
• Skills: Stärken im traditionellen Web-Development

Methodik: Wie ich zu dieser Empfehlung komme

3. Risk-Reward-Analyse

• API Gateway: Niedriges Risiko, mittlere Rewards
• Service Mesh: Hohes Risiko, hohe Rewards (langfristig)
• Hybrid: Mittleres Risiko, hohe Rewards

Methodik: Wie ich zu dieser Empfehlung komme

4. Conway's Law Consideration

• Aktuelles Team-Setup: Monolithische Strukturen
• Service Mesh erfordert Microservices-Teams
• API Gateway funktioniert mit bestehender Organisation

Personalisierung in der ZooRoyal Storefront

Personalisierung in der ZooRoyal Storefront

Disclaimer!

• Fokus auf Architektur und Technik.
• Die in der Zielgrafik benutzten Tool wie zB. trbo werden nicht in Frage gestellt.
• Es gibt künstlerische Freiheiten bei bestimmten Annahmen ;-)

Personalisierung in der ZooRoyal Storefront

• Client-Side
• Server-Side
• Hybrid (Edge-Side Includes)

Alternative 1: Client-Side Personalisierung

Technischer Ansatz

                    
	// Frontastic lädt Base-Page
	// JavaScript holt personalisierte Inhalte nach
	fetch('/api/personalization/recommendations')
	.then(data => renderPersonalizedContent(data))
                    
                

Alternative 1: Client-Side Personalisierung

Chancen

• Performance: Schnelle Initial Page Load
• Caching: Statische Seiten cachebar (CDN)
• Flexibilität: A/B Tests einfach implementierbar
• Skalierung: Keine Server-Last für Personalisierung

Alternative 1: Client-Side Personalisierung

Risiken

• SEO: Personalisierte Inhalte nicht crawlbar
• UX: Flickering/Layout-Shifts beim Nachladen
• Datenschutz: Client-Side Tracking problematisch (DSGVO)
• Performance: Zusätzliche API-Calls

Alternative 2: Server-Side Personalisierung

Technischer Ansatz

                    
                // Frontastic Server-Side Rendering
                app.get('/kategorie/:cat', async (req, res) => {
	                const user =
	                	await getUserProfile(req.session);
	                const personalizedContent =
	                	await getPersonalization(user, req.params.cat);
	                res.render('category', { content: personalizedContent });
                });
                    
                

Alternative 2: Server-Side Personalisierung

Chancen

• SEO-optimiert: Vollständiger Content für Crawler
• Bessere UX: Keine Layout-Shifts
• Datenschutz: Server-Side Processing, DSGVO-konform
• Konsistente Performance: Vorhersagbare Ladezeiten

Alternative 2: Server-Side Personalisierung

Risiken

• Caching-Probleme: Personalisierte Seiten schwer cachebar
• Server-Last: Höhere CPU/Memory-Anforderungen
• Komplexität: Session-Management, User-Tracking
• Latenz: Längere Time-to-First-Byte

Alternative 3: Edge-Side Includes (ESI)

Technischer Ansatz

Alternative 3: Edge-Side Includes (ESI)

Chancen

• Beste Performance: Statische Seiten + dynamische Fragmente
• Skalierbarkeit: CDN-Level Caching + Personalisierung
• Flexibilität: Granulare Personalisierung einzelner Bereiche
• SEO + UX: Vollständiger Content ohne Client-Side Flickering

Alternative 3: Edge-Side Includes (ESI)

Risiken

• Komplexität: ESI-Setup und Debugging schwierig
• Vendor Lock-in: Abhängigkeit von CDN-Provider (Cloudflare)
• Debugging: Schwierige Fehlersuche in verteilten Systemen
• Team-Skills: Spezialisiertes Know-how erforderlich

Meine Empfehlung für zooroyal.de

Für ZooRoyal empfehle ich Server-Side Personalisierung mit selektiver Client-Side Ergänzung.

Warum Server-Side?

• SEO-kritisch: Tierfutter ist stark Google-abhängig
• DSGVO-Compliance: Datenschutz hat höchste Priorität
• Zielgruppe: Ältere Nutzer, langsamere Geräte
• Content-Typ: Produktkataloge profitieren von vollständigem Server-Rendering

Implementierungs-Strategie:

• Phase 1: Server-Side für Produktempfehlungen
• Phase 2: Client-Side für Echtzeit-Features (Warenkorb, Wishlist)
• Phase 3: ESI für hochfrequente Bereiche (wenn Team-Skills vorhanden)

Messbare Erfolgskriterien:

• SEO: Keine Verschlechterung der Suchmaschinen-Rankings
• Performance: <2s Time-to-Interactive
• Conversion: +15% durch bessere Produktempfehlungen (Industry-Benchmark: 10-15%)
• Compliance: 100% DSGVO-konform
• Customer Satisfaction: Kunden schätzen Empfehlungen, die für sie relevant sind

Aktuelle Trends & Statistiken (2025):

• 74% der Online-Shopper sind frustriert, wenn Inhalte nicht personalisiert sind
• Personalisierung kann zu 10-15% höheren Conversion-Raten führen
• Google behält Third-Party Cookies bei, führt aber User-Choice-Prompt ein → First-Party Data wichtiger
• Mobile Commerce erreicht 2025 $1.54 Billionen → Mobile-First Personalisierung kritisch

Methodik: Wie ich zu dieser Empfehlung komme

1. User Journey Analysis

• Tierfutter-Kunden: Regelmäßige Käufer, Brand-loyal, ZooRoyal Club
• Kaufverhalten: Wiederholungskäufe, Abo-Modelle
• Gerätenutzung: Mix aus Desktop/Mobile

Methodik: Wie ich zu dieser Empfehlung komme

2. Technical Constraints

• Bestehende Infrastruktur: Frontastic + CommerceTools
• Team-Skills: Stärken im Server-Side Development
• Budget: Begrenzte Ressourcen für experimentelle Ansätze

Methodik: Wie ich zu dieser Empfehlung komme

3. Business Impact Assessment

• Revenue Impact: Personalisierung kann Conversion um 10-30% steigern
• SEO Impact: Kritisch für Organic Traffic
• Maintenance Cost: Server-Side ist langfristig wartbarer

Methodik: Wie ich zu dieser Empfehlung komme

4. Risk Mitigation

• A/B-Testing: Gradueller Rollout der Personalisierung
• Fallback-Strategie: Statische Empfehlungen als Backup, Crawler-Futter
• Monitoring: Detaillierte Performance-Metriken
• Privacy-First: First-Party Data Strategy für Post-Cookie Ära
• Mobile-Optimierung: Responsive Design für 65% mobile Traffic

Vielen Dank!

Ende der Präsentation

Fragen?

Ich freue mich auf den Austausch!

Quellen & Inspiration

• eCommerce Trends – Thoughtworks Radar
• eCommerce Trends – Gartner
• Team Topologies – Skelton & Pais
• Domain-Driven Design – Eric Evans
• Conways Law
• Personalisierung in 2025
• Google on Cookies
• Google on 3rd Party Cookies
• Mobile Commerce in 2025 / Hyper-Personalisierung
• 74% of shoppers get frustrated
• 10-15% increase in conversion rate
• AI-Driven Predictive Personalization
• Kunden finden Empfehlungen relevant
• Voice Commerce in 2030