Keine Referenzliste, sondern Denkweise: Was war das Problem, welche Architekturentscheidung ist daraus gefolgt und was hat sie gekostet.
Die Projekte sind bewusst ohne Kundennamen beschrieben. Was Sie interessiert, ist ohnehin nicht, für wen ich gearbeitet habe, sondern wie ich an eine Aufgabe herangehe.
Ausgangslage: Ein Hersteller von Industrieanlagen berät seine Kunden bis dahin ausschließlich telefonisch. Welche Anlage passt, hängt von Material, Verschmutzung, Durchsatz und einem Dutzend weiterer Größen ab. Die Kombinationen lassen sich nicht als Produktliste abbilden.
Entscheidung: Kein Filter über einen Produktkatalog, sondern ein Regelwerk. Die Auswahl rechnet aus den Eingaben ein Ergebnis, statt vorhandene Datensätze zu durchsuchen. Damit bleibt das System auch dann richtig, wenn es eine Kombination noch nie gab.
Ergebnis: Interessenten kommen mit einer konkreten Anlage ins Gespräch statt mit einer offenen Frage. Die Fachabteilung pflegt die Regeln selbst, ohne Entwicklung.
Ausgangslage: Die verbreitete Standardlösung für Registrierung und Benutzerprofile im TYPO3-Frontend hatte keinen Weg in die aktuelle TYPO3-Version. Betroffen war nicht ein Projekt, sondern jedes, das Anmeldungen braucht.
Entscheidung: Neu bauen statt patchen, und dabei Security by Design zur Grundlage machen: kein Zugriff ohne geprüfte Berechtigung, keine Rückschlüsse aus Fehlermeldungen, nachvollziehbare Einwilligungen.
Ergebnis: Daraus wurde ot-feuser, eine meiner umfangreichsten Extensions – heute quelloffen und in mehreren Projekten im Einsatz.
Ausgangslage: Ein Verlag betreibt Redaktion und Shop parallel. Der naheliegende Weg wäre gewesen, den Shop in TYPO3 nachzubauen oder die Inhalte in den Shop zu verschieben. Beides hätte eine Seite dauerhaft schlechter gemacht.
Entscheidung: Jedes System behält, was es gut kann. Statt einer Datensynchronisation eine Integration: Die Redaktion verlinkt Shop-Artikel direkt im Editor, die Artikeldaten kommen zur Laufzeit aus dem Shop.
Ergebnis: Keine doppelte Datenpflege und kein Abgleich, der nachts scheitert. Beide Systeme lassen sich unabhängig voneinander aktualisieren.
Ausgangslage: Konstruktionsdaten für tausende Bauteile kommen von einem externen Dienst. Der Dienst ist langsam und gelegentlich nicht erreichbar – jede Anfrage im Frontend war ein Risiko für die Seite.
Entscheidung: Die Abhängigkeit aus dem Seitenaufruf herausnehmen. Ein eigener Cache hält die Daten vor und erneuert sie im Hintergrund; fällt der Dienst aus, liefert die Seite den letzten bekannten Stand statt einer Fehlermeldung.
Ergebnis: Die Verfügbarkeit der Seite hängt nicht mehr an einem fremden System.
Ausgangslage: Ein über viele Jahre gewachsenes System, mehrere Versionen im Rückstand, im täglichen Einsatz. Ein Neubau hätte bedeutet, jahrelang zwei Systeme zu pflegen.
Entscheidung: Modulare Migration statt Neubau. Feature-Schalter, parallele Builds, Bereich für Bereich – das alte und das neue Frontend liefen zeitweise nebeneinander, umschaltbar pro Seitenbereich.
Ergebnis: Kein Stichtag, an dem alles gleichzeitig funktionieren musste. Jeder Schritt war einzeln zurückzunehmen.
Wenn Ihnen eine dieser Ausgangslagen bekannt vorkommt, schildern Sie mir Ihre. Die erste Einschätzung kostet nichts.