SensioLabs Interview

Wie lange sind Sie bei SensioLabs, und wie hat sich SensioLabs Deutschland seit der Gründung entwickelt?

Ich bin seit zwei Jahren bei SensioLabs und habe SensioLabs Deutschland von Anfang an mit aufgebaut. Wir sind aus einer klaren Beobachtung heraus entstanden: Im Mittelstand begegnen uns viele Unternehmen, die nicht noch ein weiteres Tool brauchen, sondern jemanden, der ihre Symfony-Projekte technisch wirklich durchdringt – von der Architektur bis zur Krisenintervention. Heute sind wir das Bindeglied zwischen dem Symfony PHP Framework und den realen Anforderungen in Deutschland: ERP-Integrationen, regulierte Branchen, langfristige Plattformen.

Symfony feiert über 20 Jahre. Wie hat sich die Positionierung von Symfony im deutschen Markt in dieser Zeit gewandelt?

Symfony war im deutschen Markt lange „nur ein PHP-Framework" – respektiert, aber in seiner Tragweite unterschätzt. Das hat sich gedreht: Heute ist Symfony die Foundation, auf der ganze Ökosysteme stehen. Shopware, eine der wichtigsten europäischen Commerce-Plattformen, baut darauf auf. Sulu kommt aus dem deutschsprachigen Raum. In Behörden, Banken und im Maschinenbau ist Symfony längst gesetzt. Was sich geändert hat, ist die Wahrnehmung: Symfony ist kein Framework mehr, das man wählt – es ist das Fundament, auf dem man baut.

SensioLabs hat Symfony als Open-Source-Framework geschaffen — und ist gleichzeitig ein kommerzielles Unternehmen. Wie erklären Sie deutschen Mittelständlern, die von Open Source primär „kostenlos" hören, was der eigentliche strategische Wert dahinter ist?

Wer bei Open Source als Erstes „kostenlos" hört, hat den Punkt verfehlt. Der eigentliche Wert ist Souveränität: Sie behalten die Kontrolle über Ihren Stack, Ihre Daten und Ihren Zeitplan – nicht ein Vendor in Kalifornien, der morgen die Roadmap ändert oder die Lizenz dreht. Lizenzkosten sind eine Fußnote; was wirklich zählt, ist der Zugang zu einem globalen Talentpool und die Fähigkeit, das System in zehn Jahren noch zu betreiben. Am Ende geht es bei Open Source nicht um den Preis, sondern um die Frage: Wem gehört die digitale Wertschöpfung in Ihrem Unternehmen? Die Antwort hat strategische und industriepolitische Tragweite.

Wir erleben in B2B-Projekten häufig, dass Entscheidungsträger zwischen proprietären SaaS-Lösungen und Open-Source-Plattformen zerrissen sind. Was sind aus Ihrer Erfahrung die Situationen, in denen Open Source klar gewinnt — und wo würden Sie es ehrlich auch nicht empfehlen?

Open Source gewinnt überall dort, wo Differenzierung gefragt ist: komplexe B2B-Logik, eigene Preiswelten, tiefe ERP-Integration, lange Lebenszyklen. Proprietäres SaaS gewinnt im Commodity-Bereich – ein simpler Standardshop, kurze Zeithorizonte, kein technisches Inhouse. Ehrlich gesagt: Wenn ein Unternehmen weder bereit noch fähig ist, technische Verantwortung zu übernehmen, soll es kein Open Source nutzen. Open Source belohnt Beteiligung. Wer rein konsumieren will, sollte ehrlich prüfen, ob ein SaaS-Modell nicht der bessere Weg ist.

Symfony ist heute nicht nur ein Framework, sondern ein ganzes Ökosystem — API Platform, Symfony UX, Blackfire. Wie nutzen B2B-Unternehmen aus dem deutschen Mittelstand dieses Ökosystem konkret? Haben Sie ein Beispiel, das Führungskräfte greifbar finden?

Ein typischer Fall aus dem Maschinenbau: Kundenportal mit individuellen Preisen, Ersatzteilkatalog, ERP-Anbindung. Symfony bildet das API-First-Backend, API Platform liefert die saubere REST-Schicht zum SAP, und darauf setzt ein modernes Frontend nach Wahl auf – React, Vue, oder was zum Team passt. Blackfire sorgt dafür, dass die Performance auch bei 50.000 Artikeln stabil bleibt. Drei Bausteine, ein konsistentes Ökosystem, ein Team. Genau das ist der Hebel, den SaaS-Anbieter strukturell nicht liefern können.

SensioLabs bietet explizit eine „Rettungsmission" für Projekte in der Krise an. Was sehen Sie, wenn Sie zu einem solchen Projekt hinzugezogen werden — welches Muster wiederholt sich am häufigsten?

Das mit Abstand häufigste Muster: Architekturentscheidungen wurden aus den falschen Gründen getroffen – „das hatten wir schon mal", „der Partner wollte das", „das war günstig". Selten wurde das eigentliche Geschäftsproblem modelliert. Dazu kommt: keine ehrliche Test-Strategie, keine Senior-Engineering-Verantwortung, und ein Backlog, der nur Features kennt, aber keine technische Schuld bewusst tilgt. Der Code ist meist nicht das Problem – die Entscheidungsstruktur dahinter ist es.

Wir haben auf e-commercianer beschrieben, dass viele B2B-Projekte nicht an der Technologie scheitern, sondern an Governance, Stakeholder-Alignment und Change Management. Deckt sich das mit dem, was SensioLabs auf der technischen Seite sieht — oder ist die Diagnose eine andere?

Das deckt sich zu 80 Prozent. Was als Tech-Schuld erscheint, ist meist Entscheidungsschuld: niemand hat den Mut gehabt, Scope zu schneiden, Stakeholder zu konfrontieren oder eine schlechte Architekturidee abzulehnen. Aber: Es gibt einen harten technischen Kern – Datenmodell, Integrationsarchitektur, Domain-Schnitt – der ein Projekt zum Scheitern bringen kann, ohne dass Governance noch retten könnte. Wer die Domäne falsch modelliert, kann mit perfektem Change Management nicht gegensteuern.

Es gibt Projekte, bei denen eine Rettung schlicht nicht mehr möglich ist — zu viele technische Schulden, zu zerrüttetes Vertrauen zwischen Auftraggeber und Team. Wie kommunizieren Sie das als externe Partei, und was raten Sie Unternehmen, die in dieser Situation stecken?

Wir sagen es klar – möglichst früh, möglichst dokumentiert. Der Sunk-Cost-Effekt ist ein psychologisches Problem, kein finanzielles: Das, was bereits investiert wurde, ist ausgegeben – egal, was Sie jetzt tun. Die einzige relevante Frage ist, was die nächsten investierten Euro bringen. Unsere Empfehlung in solchen Fällen ist fast immer ein klar abgegrenzter Neuanfang mit strukturiertem Auslauf des Altsystems – nicht ein endloses Refactoring, das Vertrauen weiter zerstört. Eine ehrliche Diagnose ist wertvoller als eine bequeme.

SensioLabs bietet das Konzept der „Progressiven Migration" an — Modernisierung ohne Betriebsunterbrechung. In der B2B-Commerce-Praxis sprechen wir oft von Replatforming als einem großen, riskanten Sprung. Wie funktioniert der progressive Ansatz konkret, und für welche Ausgangssituationen eignet er sich?

Wir setzen auf das Strangler-Fig-Pattern: Das neue System wird vor das alte gesetzt, übernimmt schrittweise einzelne Routen, Domänen oder Bounded Contexts – und am Ende steht das Altsystem still. Funktioniert immer dann, wenn ein Geschäft live ist und keinen Stillstand verträgt: Commerce-Plattformen, Kundenportale, ERP-Frontends. Big Bang funktioniert in Konferenzfolien, in der Realität fast nie. Progressive Migration ist die einzige Variante, die sich verlässlich planen lässt.

Viele Mittelständler schieben eine Modernisierung ihres technologischen Fundaments jahrelang auf, weil der „richtige Zeitpunkt" nie kommt. Was sind für Sie die drei klarsten Warnsignale, dass ein Unternehmen jetzt handeln muss — auch wenn es operativ wehtut?

Erstens: Sie finden keine Entwickler mehr – Kandidaten lehnen den Stack im Bewerbungsgespräch ab. Zweitens: Triviale Änderungen brauchen Wochen, weil niemand mehr weiß, was woran hängt. Drittens: Security-Updates und Compliance-Anforderungen blockieren, weil der Unterbau zu alt ist. Wenn auch nur eines davon zutrifft, ist der „richtige Zeitpunkt" bereits vorbei.

Beim progressiven Migrationsprozess bleibt das alte System zeitweise parallel zum neuen aktiv. Das erzeugt Komplexität und Kosten. Wie überzeugen Sie einen CFO, der nur den Doppelaufwand sieht?

Was wie Doppelaufwand aussieht, ist in Wahrheit verteiltes Risiko. Big-Bang-Projekte scheitern in der Branche zu 30 bis 60 Prozent; ein Totalausfall kostet ein Vielfaches der Parallelphase. Progressive Migration liefert ab Woche eins Geschäftswert, ist jederzeit ausstiegsfähig und verteilt Investitionen über die Laufzeit. Genau deshalb passt der Ansatz so gut zur Realität moderner Teams: Es lassen sich klare Prioritäten setzen, einzelne Domänen gezielt steuern, und das Team arbeitet immer am wertvollsten Schnitt – nicht an einem Mammutprojekt, das erst in zwei Jahren liefert. Die teure Option ist die, die der CFO eigentlich vermeiden will: alles auf eine Karte.

„Headless Commerce" und „API-First" sind Begriffe, die inzwischen auch in Mittelstandskonferenzen auftauchen — oft ohne echtes Verständnis dahinter. Was muss ein Head of E-Commerce oder CTO eines B2B-Unternehmens wirklich verstanden haben, bevor er eine Architekturdiskussion führt?

Drei Dinge. Erstens: Architektur folgt Organisationsstruktur (Conway's Law) – wer ein monolithisches Team hat, sollte nicht headless gehen. Zweitens: Headless verschiebt Komplexität nach außen – einfacherer Kern, aber deutlich mehr Verantwortung an den Rändern. Drittens: Diese Entscheidung ist auf mittlere Sicht irreversibel. Ohne echtes Product-Mindset im Haus wird Headless zu einem teuren Bauchladen.

Sinnvoll wird Headless oder API-First dann, wenn mehrere Touchpoints bedient werden müssen – Webshop, Kundenportal, mobile App, Außendienst-Tool, EDI-Schnittstellen –, wenn unterschiedliche Frontends in unterschiedlicher Geschwindigkeit weiterentwickelt werden sollen, oder wenn die Backend-Logik komplex genug ist, dass sie eigenständig versioniert und gepflegt werden muss. Im B2B trifft genau das oft zu: ein Produkt, viele Kanäle, lange Lebenszyklen. Wer dagegen einen einzigen klassischen Webshop betreibt und in den nächsten fünf Jahren auch nichts anderes plant, fährt mit einem integrierten Stack besser – schneller, billiger, weniger Reibung.

SensioLabs setzt stark auf API Platform als Teil des Symfony-Ökosystems. Welche Rolle spielt eine saubere API-Architektur speziell im B2B-Kontext — bei ERP-Integration, Kundenportal-Logik, komplexen Preiswelten?

B2B ist Integration. ERP, PIM, CRM, Händlerportale, Konfiguratoren, EDI – alles spricht miteinander, und die Schnittstellen entscheiden über die Lebensdauer der Plattform. API Platform liefert OpenAPI, JSON-LD und eine konsistente Ressourcen-Modellierung von Haus aus – das spart Monate gegenüber individuell entwickelten APIs. Besonders bei komplexen Preiswelten lohnt es sich, den Preis als eigenen Bounded Context mit klarer API zu schneiden – das ist der Punkt, an dem Headless im B2B den eigentlichen Hebel hat.

Wie viel Architektur-Entscheidung darf eine externe Agentur oder ein Systemhaus treffen — und wo muss das intern verankert sein, damit ein Unternehmen langfristig handlungsfähig bleibt?

Architekturprinzipien gehören intern verankert – wer entscheidet, dass etwas ein Microservice wird oder nicht, was die Datenhoheit ist, wie man Domänen schneidet. Die Implementierung dieser Prinzipien kann extern erfolgen, kein Problem. Wer keine internen Architektur-Verantwortlichen hat, ist dauerhaft von Beratern abhängig – und das ist genau die Falle, vor der wir Kunden warnen. Die Entscheidung, wer entscheidet, ist selbst eine strategische Entscheidung.

SensioLabs positioniert sich bewusst nicht als Ersatz für ein internes Team, sondern als Verstärkung. Was bedeutet das in der Praxis — welche Aufgaben sollten Ihrer Meinung nach immer inhouse bleiben?

Inhouse: Domänenwissen, Architekturprinzipien, Code-Review-Hoheit, geschäftliche Entscheidungen. Extern: Spitzenlastkapazität, Spezial-Know-how, das Mustererkennungs-Wissen aus 50 ähnlichen Projekten, der externe Blick. Wir kommen, wenn wir gebraucht werden, und ziehen uns zurück, wenn das Team trägt – das ist der Anspruch. Wer sein Inhouse-Team verliert, verliert mittelfristig die Kontrolle über sein Produkt.

Viele Mittelstandsunternehmen haben Schwierigkeiten, qualifizierte Symfony- oder PHP-Entwickler zu finden und zu halten. Wie beeinflusst das den Umgang mit Open-Source-Projekten — und wie lösen Sie dieses Problem für Ihre Kunden?

Open Source ist hier ein Vorteil, kein Nachteil: Symfony hat eine starke DACH-Community, und Entwickler arbeiten viel lieber an Stacks, die sie aus Vorträgen, Open-Source-Beiträgen und ihrer eigenen Karriere kennen. Unsere Antwort sind hybride Teams mit klarer Wissensübergabe – Mentorship und Knowledge Transfer sind Vertragsbestandteil, nicht Goodwill. Mittelständler sollten in Junior-Programme investieren, nicht nur Senior einkaufen wollen. Den Markt aufzukaufen funktioniert nicht mehr; ihn auszubilden schon. Und für alle kurzfristigen Ressourcen-Bedarfe – Spitzenlast, Spezial-Know-how, Überbrückung – ist SensioLabs genau der Partner, der einspringt, ohne das interne Team zu ersetzen.

Worauf sollte ein Unternehmen beim Auswahlprozess eines Technologiepartners für ein B2B-E-Commerce-Projekt besonders achten — abseits von Referenzlisten und Präsentationsfolien?

Erstens: Sprechen Sie mit Bestandskunden über deren Krisen, nicht über deren Erfolge – wie hat sich der Partner verhalten, als es wehgetan hat? Zweitens: Lernen Sie das Team kennen, das tatsächlich liefert, nicht das Sales-Team. Drittens: Misstrauen Sie Methodologie-Theater – wer dicke Prozessdokumente vor working software stellt, hat selten geliefert. Und viertens: Die Bereitschaft, Anforderungen zu hinterfragen oder abzulehnen, ist ein Qualitätsindikator – nicht das Gegenteil.

SensioLabs hat eine KI-Machbarkeitsstudie als neuen Service im Portfolio. Welche konkreten KI-Anwendungsfälle sehen Sie derzeit bei deutschen B2B-Unternehmen als wirklich reif — und was ist noch Wunschdenken?

Reif: Interne Suche und Wissensmanagement, strukturierte Datenextraktion aus Dokumenten, Support-Automatisierung erster Stufe, Code-Generierung, Produktdatenanreicherung. Wunschdenken: Autonome Agenten, die ganze Abteilungen ersetzen, oder KI als Silver Bullet für schlecht modellierte Prozesse. KI verstärkt, was da ist – auch die schlechten Daten und die unklaren Verantwortlichkeiten. Wer keine saubere Domäne hat, bekommt mit KI nur schnellere Fehler.

Viele B2B-Entscheider fürchten, mit KI-Projekten Ressourcen zu verbrennen, ohne klaren ROI. Was sind aus Ihrer Sicht die Voraussetzungen, die ein Unternehmen erfüllen muss, bevor eine KI-Initiative Sinn ergibt?

Drei. Erstens: Die Daten sind strukturiert und zugänglich – ein gepflegtes PIM, ein sauberes ERP, klar definierte Datenquellen. Hier scheitern die meisten, lange bevor das erste Modell läuft. Zweitens: Der Prozess, der automatisiert werden soll, ist verstanden und dokumentiert – KI ist kein Ersatz für Prozessanalyse. Hier hat sich allerdings etwas Spannendes geändert: KI kann heute helfen, bestehende Prozesse aus dem Code abzuleiten und für Stakeholder sichtbar zu machen – gerade in gewachsenen Mittelstandssystemen, in denen die ursprünglichen Entscheidungen oft Jahrzehnte zurückliegen und niemand mehr im Haus ist, der sie erklären kann. Das ist ein realer Hebel. Drittens: Es gibt einen internen Verantwortlichen für KPI und Qualität, nicht nur ein Innovation-Lab. Ohne diese drei Voraussetzungen entstehen Pilotprojekte, die niemand vermisst, wenn sie verschwinden.

Wenn Sie einem Head of E-Commerce eines deutschen Mittelstandsunternehmens — sagen wir, Maschinenbau, 500 Mitarbeiter, B2B-Vertrieb im Wandel — einen einzigen Ratschlag für 2026 mitgeben könnten: Was wäre das?

Hören Sie auf, Projekte zu kaufen – fangen Sie an, eine Plattform zu bauen. Stellen Sie sich die Frage: Wer im Haus verantwortet das digitale Fundament in fünf Jahren? Wenn die Antwort „ein externer Dienstleister" lautet, haben Sie ein strategisches Problem. Holen Sie sich einen Head of Engineering, geben Sie ihm einen Fünf-Jahres-Horizont, und treffen Sie diese Entscheidung 2026. 2030 ist es zu spät.