Tech Platform: VECTOR SOLUTIONS

#Projektüberblick

Vector Solutions gehört zur Gdingener Gruppe VECTOR, die seit 1988 am Markt ist und mit Verstärkern für Kabelfernsehanlagen begonnen hat. 2001 brachte das Unternehmen DOCSIS in die polnischen Kabelnetze, seit 2007 entstehen dort Telemetriesysteme, und heute arbeiten über zweihundert Software-, Systems- und Hardware-Ingenieure im Unternehmen. Die Kunden sind Kabelnetzbetreiber, Telekommunikationsunternehmen und Fernsehsender, also Käufer, die zuerst ein Datenblatt lesen und erst danach eine Startseite.

Das Projekt kam 2017 zu uns, im selben Jahr, in dem die Gruppe den Rebranding-Prozess eröffnete, den sie 2019 mit der Gründung von VECTOR BLUE HUB abschloss. Die Umsetzung dauerte rund sechs Wochen, gerechnet von der Umfangsanalyse bis zur Veröffentlichung.

Wichtig für das Verständnis der Arbeitsteilung: Layout und Platzierung der Elemente kamen vom Kunden. Unser Anteil waren die Templates, das responsive Verhalten, das Content-Modell, die Integrationen und die Performance-Arbeit. Das klingt nach weniger, als es ist. Der sichtbare Entwurf ist bei einem technischen Katalog der kleinere Teil des Problems; der größere sitzt darunter, in der Frage, wie viele Varianten eine Lösung haben darf, wer welche Spezifikation sehen darf und was mit einer Seite passiert, wenn ein angebundenes Fremdsystem gerade nicht antwortet.

#Hintergrund des Kunden

#Führungsrolle in der Branche

Vector Solutions hat sich als Technologieanbieter etabliert durch:

• Europäische Präsenz: Aktivitäten in Polen und in ganz Europa
• Innovationsfokus: kontinuierliche Entwicklung neuer technologischer Lösungen
• Sektorexpertise: tiefes Verständnis der Kabel-, Telekommunikations- und Medienbranche
• Partnerschaftlichen Ansatz: kollaborative Beziehungen zu bedeutenden Marktteilnehmern
• Lösungsportfolio: ein breites Spektrum an Kommunikations- und Infrastrukturtechnologien

#Was daraus für die Website folgte

Drei Jahrzehnte im Hardwaregeschäft hinterlassen eine Spur im Content-Modell. Der Lösungskatalog umfasst Produkte aus mehreren Technologiegenerationen: einiges läuft weiter in Betreibernetzen, anderes wird ausgemustert, und die Dokumentation zu beidem muss nebeneinander erreichbar bleiben. Eine Broschüre mit fünf Leistungskacheln kam deshalb nicht infrage. Die Seite musste ein Modell tragen, in dem eine Lösung viele Varianten hat, jede Variante ihre eigene Spezifikation, und in dem eine Spezifikation manchmal nur für einen angemeldeten Partner sichtbar ist.

Die zweite Folge betrifft den Leser. Ein Ingenieur bei einem Kabelnetzbetreiber sucht einen einzelnen Parameter, keine Erzählung über Innovationskraft. Suche und Filterung auf Attributebene standen darum über der visuellen Schicht, deren Layout ohnehin vom Kunden kam. Diese Reihenfolge ist keine Geschmacksfrage: Wer bei einem Katalog dieser Art zuerst die Bildsprache löst und die Attributstruktur später nachzieht, baut sie am Ende zweimal.

#Technische Umsetzung

#Plattformarchitektur

Der Stack besteht aus WordPress mit einem dedizierten Theme, Redis für den Objekt-Cache, Varnish davor für den Seiten-Cache und Cloudflare als Randschicht. Drei Cache-Ebenen in einer Installation wirken nach Übermaß, bis man sieht, dass jede eine andere Art von Anfrage beantwortet. Cloudflare liefert statische Dateien und anonyme Seiten aus, ohne dass der Ursprungsserver überhaupt beteiligt ist. Varnish hält die zusammengesetzten Katalogansichten, deren Aufbau ein gutes Dutzend Datenbankabfragen kostet. Redis verkürzt genau diese Abfragen für alles, was es bis zu PHP schafft. Nimmt man eine der drei Ebenen heraus, übernimmt die nächsttiefere ihre Last, und zwar zu einem deutlich höheren Preis pro Anfrage.

Die architektonische Spannung dieses Projekts sitzt exakt dort, wo Caching auf Personalisierung trifft. Die Seite soll einen anonymen Besucher von einem angemeldeten Partner und von einem internen Mitarbeiter unterscheiden und drei Personen drei verschiedene Fassungen derselben URL zeigen. Ein Cache an der Netzwerkkante mag das per Definition nicht, denn sein ganzer Gewinn stammt daraus, vielen Menschen dasselbe Byte auszuliefern. Die Auflösung bestand darin, die Schichten zu trennen: Seitengerüst und Katalog sind gemeinsam und werden hart gecacht, während alles, was von einer Rolle abhängt, nach der Anmeldung per eigener Anfrage nachgeladen wird und niemals in Varnish landet. Der Cache-Schlüssel enthält deshalb keine Nutzeridentität, und genau das macht ihn brauchbar.

Zentrale Systemkomponenten entstanden entlang dieser Trennung. Das dynamische Angebotsmanagement erlaubt die Konfiguration zusammengesetzter Angebote mit mehrstufigen Preislisten und Paketen und gibt sie an die Abrechnungssysteme weiter, statt Preise an zwei Stellen zu pflegen. Die interaktive Portfolio-Präsentation zeigt Fallstudien und Projekte mit Filterung und lädt Inhalte nach, ohne die Ansicht neu aufzubauen. Die Echtzeit-Datenintegration bindet externe Quellen ein und aktualisiert Inhalte automatisch, sodass redaktionelle Arbeit nicht daran hängt, dass jemand eine Zahl von Hand abschreibt.

#Frontend-Erlebnis

Weil Layout und Platzierung der Elemente vom Kunden kamen, bestand unser Teil darin, sie in Templates, responsives Verhalten und ein Content-Modell zu übersetzen, das sich nach dem Start pflegen lässt. Über Ästhetik gab es hier keinen Streit, über die Reihenfolge der Information sehr wohl.

Die Oberfläche passt Inhalte an das Nutzerprofil an, erlaubt das Filtern von Lösungen über mehrere Dimensionen gleichzeitig und stellt sie in einem Vergleichswerkzeug nebeneinander. Mehrdimensionales Filtern ist die Stelle, an der ein technischer Katalog am häufigsten umkippt: Jedes zusätzliche Attribut vervielfacht die Zahl möglicher Kombinationen, und eine naive Umsetzung fragt die Datenbank einmal pro Filter. Hier wird die Attributmenge einmal berechnet und in Redis gehalten, und das Umlegen eines einzelnen Filters lädt nicht die Seite neu, sondern tauscht die Ergebnisliste aus. Das ist weniger eine Frage des Komforts als eine Frage der Serverlast, denn ein Besucher, der fünf Filter durchprobiert, erzeugt sonst fünf vollständige Seitenaufbauten.

Das Layout ist Mobile-First und erfüllt WCAG 2.1. In einem Produktkatalog heißt das vor allem, dass Spezifikationstabellen Kopfzellen besitzen, die mit den Datenzellen verknüpft sind, und dass sich Filter mit der Tastatur bedienen lassen. Eine Parametertabelle ohne diese Verknüpfung ist für einen Screenreader eine Folge von Zahlen ohne Bedeutung, und diese Tabellen sind der Hauptinhalt dieser Seite, nicht deren Beiwerk.

#Backend-Systeme

Die Inhaltsverwaltung arbeitet mit eigenen Inhaltstypen für Lösungen und Fallstudien, einer ausgebauten Taxonomie, mehrsprachigen Inhalten, einem Freigabeprozess und einer Versionierung der Änderungen. Der Grund für die eigenen Inhaltstypen ist banal und trotzdem entscheidend: Eine Produktvariante, die als normaler Beitrag abgelegt wird, verliert ihre Attribute in dem Moment, in dem jemand den Katalog anders sortieren will.

Die Nutzerverwaltung stützt sich auf rollenbasierte Zugriffssteuerung, ein Partnerportal, Kundenkonten, Lead-Verfolgung mit CRM-Anbindung und ein Auswertungs-Dashboard. Entscheidend ist dabei nicht die Liste der Rollen, sondern der Ort der Prüfung. Sie sitzt dort, wo Inhalte geladen werden, nicht im Menü.

Auf der Integrationsseite spricht WordPress mit Salesforce als CRM, mit HubSpot für die Marketing-Automatisierung, mit Zahlungs-Gateways und mit den Abrechnungssystemen des Kunden. Jede dieser Verbindungen läuft über einen eigenen Adapter, nie direkt aus einem Template heraus.

#Erweiterte Funktionen

#Dynamische Angebotssysteme

Die Angebotskonfiguration erlaubt modulare Bündel, die Verwaltung von Preisstufen, Regeln zur geografischen Verfügbarkeit, das Anwenden von Aktionen und Rabatten sowie die automatisierte Erzeugung von Dokumenten. Der eigentliche Aufwand liegt nicht im Rechnen, sondern in der Reihenfolge der Regeln. Ein Mengenrabatt, eine partnerspezifische Preisliste und eine befristete Aktion können auf dieselbe Position wirken, und wenn nicht festgelegt ist, welche Regel zuerst greift, erzeugen zwei Bearbeiter am selben Nachmittag zwei verschiedene Angebote für denselben Kunden. Diese Reihenfolge gehört deshalb ins System und nicht in eine Arbeitsanweisung.

Für einzelne Partner existieren individuelle Preislisten, Mengenstaffeln, White-Label-Optionen, ein API-Zugang für größere Kunden und dedizierte Werkzeuge für die Kontenbetreuung. Der Preis selbst bleibt dabei immer im Abrechnungssystem des Kunden, nicht im CMS. Doppelte Preispflege ist die Fehlerquelle, die sich in solchen Projekten am spätesten zeigt und am teuersten korrigiert wird.

#Echtzeit-Dashboard

Das Dashboard visualisiert Branchentrends, Kennzahlen zur Technologieverbreitung, Marktentwicklung und Wettbewerbsbeobachtung und meldet sich über konfigurierbare Warnungen. Die Ansichten lassen sich filtern, über Zeiträume vergleichen, geografisch aufschlüsseln, exportieren und als geplanter Bericht verschicken.

Technisch ist das interessante Detail nicht die Darstellung, sondern die Frequenz. Die Aktualisierungsrate richtet sich danach, wie schnell sich eine Größe tatsächlich bewegt, und ist nicht als ein einziger Wert für das ganze Dashboard gesetzt. Diese Unterscheidung entscheidet über die Rechnung: Alles alle fünf Sekunden abzufragen wirkt in einer Demonstration beeindruckend und erzeugt über Jahre Datenverkehr, den jemand bezahlt, ohne dem Leser eine einzige Information zu liefern, die er nicht eine Minute später ebenso gehabt hätte.

#Personalisiertes Nutzererlebnis

Die Personalisierung stützt sich auf eine Einordnung nach Branche, Rolle und Interesse, auf die Beobachtung des Verhaltens auf der Seite, auf Inhaltsvorschläge, auf rollenspezifische Einstiegsseiten und auf zielgerichtete Benachrichtigungen. Sie ist zugleich die Funktion, die am direktesten gegen die Cache-Strategie arbeitet, weshalb sie konsequent als Nachladung ausgeführt ist und nie in die gecachte Seitenauslieferung hineinreicht.

#Performance und Skalierbarkeit

#Technische Optimierung

Auf der Geschwindigkeitsseite steht serverseitiges Rendering für den ersten Aufbau, verzögertes Laden für Inhalte unterhalb des sichtbaren Bereichs, Bildoptimierung inklusive WebP, das Inlining von kritischem CSS und die Überarbeitung der Datenbankabfragen. Der letzte Punkt ist bei einem Katalog dieser Größe der wirksamste, weil er die Abfragen betrifft, deren Kosten mit der Zahl der Varianten wachsen statt konstant zu bleiben.

Die Cache-Strategie umfasst die drei beschriebenen Ebenen, das Zwischenspeichern dynamischer Inhaltsfragmente, das Puffern von API-Antworten, Richtlinien für den Browser-Cache und definierte Abläufe zur Invalidierung. Der Invalidierung gilt dabei die größere Aufmerksamkeit: Ein Cache, den niemand gezielt leeren kann, wird beim ersten falsch ausgelieferten Preis abgeschaltet, und danach spricht in dem Projekt niemand mehr über Caching.

Für die Skalierung sorgen eine Infrastruktur, die sich an der Last ausrichtet, Lastverteilung, Lesereplikate der Datenbank, die Auslagerung zentraler Funktionen in eigene Dienste und eine kontrollierte Leistungsreduzierung unter Last. Letzteres bedeutet hier konkret, dass unter Druck zuerst die aufwendigen Zusatzansichten ausfallen und nicht die Produktseite.

#Sicherheitsmaßnahmen

Die Absicherung umfasst durchgängige SSL/TLS-Verschlüsselung, regelmäßige Sicherheitsaudits und Penetrationstests, eine Web Application Firewall, Schutz gegen Überlastungsangriffe und Systeme zur Angriffserkennung, ergänzt durch Wordfence auf Anwendungsebene. Beim Datenschutz kommen DSGVO-Konformität, Verschlüsselung im Ruhezustand und bei der Übertragung, Zugriffsprotokollierung, regelmäßige Sicherungen und ein Plan für die Wiederherstellung hinzu.

Der Teil, der hier mehr zählt als die Aufzählung, ist die Verbindung von Zugriffsrechten und Auslieferung. In einem Katalog, in dem ein Teil der Spezifikationen unter einer Vertraulichkeitsvereinbarung steht, ist ein ausgeblendeter Menüpunkt kein Schutz. Wer die Adresse kennt, tippt sie ein.

#SEO und digitales Marketing

#Suchmaschinenoptimierung

Technisch stehen Schema-Auszeichnung für Organisation und Leistungen, XML-Sitemaps mit Prioritäten, eine saubere URL-Struktur, Canonical-Tags und eine interne Verlinkungsstrategie. Inhaltlich kommen branchenspezifische Landingpages, ein Technologie-Glossar, optimierte Fallstudien, Fachbeiträge und eine Materialbibliothek dazu. International greifen hreflang für die Sprachversionen, länderspezifische Varianten, lokale Optimierung und Linkaufbau über Märkte hinweg.

Bei einem Katalog mit vielen Varianten ist die heikelste Entscheidung nicht die Auszeichnung, sondern die Frage, welche Filterkombinationen überhaupt eine eigene indexierbare Adresse verdienen. Wer jede Kombination als URL freigibt, produziert in kurzer Zeit mehr Adressen, als das Angebot Produkte hat, und die Suchmaschine verteilt ihr Crawl-Budget danach auf Varianten statt auf die Seiten, die verkaufen.

#Analysen und Erkenntnisse

Die Analytik stand seit dem Start nicht still. Die Umsetzung von 2017 startete auf Universal Analytics, weil Google Analytics 4 damals noch nicht existierte; der Wechsel kam später im Rahmen der Wartung. Das gehört ausdrücklich erwähnt, weil Projektbeschreibungen den heutigen Stack routinemäßig als den Stack des Starts ausgeben, und dann lässt sich eine Entwurfsentscheidung nicht mehr von einem Wechsel unterscheiden, den ein Anbieter erzwungen hat.

Jenseits des Werkzeugs erfasst die Messung eigene Ereignisse, die Trichteranalyse und die Wege der Nutzer durch die Seite. In einem technischen Katalog ist das wertvollste Ereignis nicht das Absenden eines Formulars, sondern der Download einer Spezifikation: Er zeigt, welche Produktvariante einen Ingenieur tatsächlich beschäftigt, lange bevor jemand eine Anfrage schreibt.

#Ergebnisse und Wirkung

An dieser Stelle stand früher eine Reihe genauer Prozentwerte zu Anfragen, Verweildauer, Portalnutzung und Vertriebszyklen. Keiner davon hält einer Prüfung gegen unsere eigenen Unterlagen stand. Das Projekt ging 2017 live, und die Messungen, falls sie je erhoben wurden, liegen in einem Postfach, auf das wir keinen Zugriff mehr haben. Zahlen, die als Messung auftreten und ihre Quelle nicht nennen können, sind schlechter als gar keine Zahlen. Deshalb steht hier, was sich ehrlich sagen lässt.

Die Performance-Arbeit richtete sich auf drei Größen. Erstens auf das Gewicht der Auslieferung, indem die Katalogansichten über die Varnish-Ebene aus PHP herausgehalten werden. Zweitens auf die Zeit bis zum ersten Byte, indem die Datenbankarbeit hinter den Ansichten verkürzt wurde, die sich nicht cachen lassen. Drittens auf die Cache-Trefferquote, die bei einer Seite dieses Zuschnitts darüber entscheidet, ob die ersten beiden überhaupt eine Rolle spielen, denn ein Fehlgriff führt die ganze Anfrage bis zum Ursprungsserver, wie gut dieser auch abgestimmt sein mag.

Die Zuverlässigkeit ruht auf dem Ausfallverhalten, das weiter unten beschrieben ist, nicht auf einer Verfügbarkeitsangabe: Der Ausfall eines externen Systems beeinträchtigt einen Abschnitt und nicht die Seite, und die alltägliche Last liegt weit genug unter der getesteten Obergrenze, dass eine Produktankündigung keinen Noteinsatz auslöst. Operativ blieb von der Umsetzung vor allem, dass Angebote nicht mehr von Hand zusammengestellt werden und dass Partner Unterlagen selbst ziehen, statt sie beim Support anzufragen.

#Herausforderungen und Lösungen

#Herausforderung 1: komplexe Integrationsanforderungen

Problem: die Anbindung mehrerer externer Systeme (CRM, Abrechnung, Branchendatenbanken) bei gleichzeitiger Wahrung der Performance.

Lösung: eine Zwischenschicht, in der WordPress nie direkt mit einem Kundensystem spricht, sondern über einen eigenen Adapter je System. Der Datenabruf läuft asynchron, sodass ein nicht erreichbares CRM das Rendern der Seite nicht blockiert, und die Antworten werden mit einer eigenen Lebensdauer pro Quelle zwischengespeichert, weil sich eine Preisliste einmal im Quartal ändert und ein Lagerbestand innerhalb einer Stunde.

Die wichtigste Entscheidung betraf den Fall, dass eine Integration ausfällt. Das Standardverhalten der meisten Erweiterungen ist eine Fehlermeldung oder ein leerer Abschnitt, was auf einer Vertriebsseite so aussieht, als sei das ganze Angebot kaputt. Hier trägt jeder Adapter einen Rückfallwert: die letzte bekannte Antwort aus dem Cache, und wenn auch die fehlt, eine statische Fassung des Abschnitts. Der Besucher sieht dann eine Seite ohne Live-Panel statt einer Fehlermeldung. Der Ausfall eines Fremdsystems wird damit zu einem Ereignis für das Monitoring, nicht für den Leser.

#Herausforderung 2: Performance bei Echtzeitdaten

Problem: Live-Daten anzeigen, ohne die Ladezeit der Seite zu belasten.

Lösung: Live-Daten blockieren den ersten Aufbau nicht. Die Seite kommt ohne sie vollständig an, das Dashboard lädt danach über getrennte Endpunkte nach, aufgeteilt in kritische und solche, die warten können. Referenzdaten, die sich selten ändern, liegen im Browser, sodass ein zweiter Besuch dem Server dieselbe Frage nicht erneut stellt.

Diese Reihenfolge hat einen Nebeneffekt, der sich erst im Betrieb zeigt: Weil das Grundgerüst der Seite ohne die Fremddaten auskommt, bleibt es auch dann auslieferbar, wenn eine Datenquelle langsam antwortet. Ein Zeitlimit im Adapter ist damit eine harmlose Einstellung und keine Entscheidung darüber, ob die Seite erscheint.

#Herausforderung 3: Komplexität mehrerer Nutzerrollen

Problem: unterschiedliche Nutzertypen (Partner, Kunden, Interessenten, interne Mitarbeitende) mit verschiedenen Bedürfnissen und Berechtigungen.

Lösung: rollenbasierte Zugriffssteuerung mit getrennten Dashboard-Ansichten für Partner, Kunden und interne Mitarbeitende sowie ein Menü, das Unerreichbares ausblendet, statt zu einer Ablehnungsseite zu führen.

Die Falle solcher Systeme ist immer dieselbe: Berechtigungen werden an der Oberfläche geprüft und nicht an den Daten. Ein ausgeblendeter Menüpunkt schützt nicht davor, dass jemand die Adresse von Hand eintippt, und in einem Katalog, in dem ein Teil der Spezifikationen unter einer Vertraulichkeitsvereinbarung steht, ist das keine Kosmetik. Die Rollenprüfung sitzt deshalb dort, wo Inhalte geladen werden, und die Ansichtsschicht spiegelt nur, was weiter unten längst entschieden wurde. Derselbe Mechanismus bildet den Cache-Schlüssel, sodass ein Partner nie eine Seite erhält, die für jemanden mit anderen Rechten gebaut wurde.

#Herausforderung 4: Lastspitzen bei Großereignissen

Problem: Größere Produktankündigungen trieben den Datenverkehr deutlich über den Alltagswert, konzentriert auf ein kurzes Fenster.

Lösung: Statische Dateien kommen aus dem CDN, die Datenbankabfragen wurden auf die durchgesehen, deren Kosten mit der Kataloggröße wachsen, und nicht kritische Vorgänge wie der Versand von Benachrichtigungen oder der Neuaufbau des Suchindex wanderten in eine Warteschlange und laufen außerhalb der Nutzeranfrage.

Der Lasttest vor einer Ankündigung lief gegen eine Kopie der Produktion und nicht gegen eine leere Installation, und das ist der wichtigste Satz dieses Abschnitts. Die Performance von WordPress mit einem Katalog aus mehreren tausend Varianten und einem Dutzend Integrationen hat nichts mit der Performance einer frischen Installation samt Demo-Theme zu tun. Der Engpass war am Ende nicht PHP, sondern die Cache-Trefferquote: Bei einer Ankündigung trifft der Verkehr auf eine einzige Adresse, die vorher niemand besucht hat, sodass die ganze Welle gleichzeitig beim Ursprungsserver ankommt. Den Cache vor der Veröffentlichung aufzuwärmen ist billiger, als Kapazität vorzuhalten, die den Rest des Quartals ungenutzt bleibt.

#Laufender Support und Weiterentwicklung

#Wartungsprogramm

Die technische Betreuung umfasst Monitoring mit Alarmierung, regelmäßige Sicherheitsupdates, periodische Performance-Überprüfungen und Lasttests vor größeren Produktankündigungen. Der letzte Punkt ist keine Formsache, denn genau Ankündigungen erzeugen Verkehr auf Adressen, die vorher niemand besucht hat, also den einen Fall, in dem der Cache nicht hilft.

Auf der Inhaltsseite laufen die Ergänzung von Fallstudien, die Pflege des Produktportfolios, die Einbindung von Branchennews, die laufende SEO-Arbeit und die Auswertung der Messdaten.

#Kontinuierliche Verbesserung

Die Weiterentwicklung folgt einer Roadmap, nimmt Rückmeldungen der Nutzer auf, übernimmt neue Technologien dort, wo sie etwas lösen, und optimiert Performance in Schritten statt in einem großen Umbau. Dazu kommt die Beratung zur digitalen Strategie, zur Einordnung technischer Entwicklungen, zum Vergleich mit dem Wettbewerb und zur Verbesserung der Nutzerführung.

#Zusammenfassung des Technologie-Stacks

#Kernplattform

WordPress mit einem dedizierten Vector-Solutions-Theme, Advanced Custom Fields Pro für die Attributstruktur des Katalogs, eine eigene Erweiterungssammlung für die projektspezifischen Funktionen und WPML für die Mehrsprachigkeit.

#Performance und Sicherheit

Redis als Objekt-Cache, Varnish als Seiten-Cache, Cloudflare als Randschicht mit Schutzfunktionen, Wordfence auf Anwendungsebene und WP Rocket für die Optimierung der Auslieferung im Frontend.

#Integrationen

Salesforce als CRM, HubSpot für die Marketing-Automatisierung, Zahlungs-Gateways, die Abrechnungssysteme des Kunden sowie die Webanalyse. Letztere startete 2017 auf Universal Analytics; Google Analytics 4 kam erst später im Rahmen der Wartung dazu.

#Entwicklungswerkzeuge

Git für die Versionskontrolle, Docker für die lokale Umgebung, GitHub Actions für die Auslieferungskette und ein Staging-Ablauf, der nahe an der Produktion liegt, weil sich das Verhalten dieses Projekts anders nicht prüfen lässt.

#Projektverlauf

Die Umsetzung dauerte rund sechs Wochen, von der Umfangsanalyse bis zur Veröffentlichung. Layout und Platzierung der Elemente kamen vom Kunden, sodass die Phase, die in anderen Projekten den größten Teil des Kalenders frisst, hier entfiel. Diese Zeit floss stattdessen in das Content-Modell und die Integrationen, also in die Teile, die auf keinem Entwurf zu sehen sind und die darüber entscheiden, ob sich eine Seite nach dem Start pflegen lässt.

Die entscheidende Weichenstellung fiel in der Testphase. Die Pfade, auf denen der Verkehr tatsächlich läuft, wurden gegen eine Kopie der Produktion geprüft und nicht gegen eine saubere Installation mit Demodaten. Bei einem Katalog dieser Größe ist der Unterschied grundlegend: Eine Abfrage, die über zwanzig Produkte in wenigen Millisekunden zurückkommt, kann über mehrere tausend Varianten um zwei Größenordnungen wachsen, und auf einer leeren Installation sieht das niemand. Dasselbe gilt für den Cache, dessen Wirksamkeit sich nur an einer realen Verteilung der Einstiegspunkte messen lässt.

Nach dem Start ging das Projekt in die Wartung über: Monitoring und Alarmierung, regelmäßige Sicherheitsupdates, periodische Performance-Überprüfungen und Lasttests vor größeren Produktankündigungen. Diese Reihenfolge ist bewusst gewählt. Wer die Lastprüfung erst nach der Ankündigung ansetzt, misst einen Zustand, an dem er nichts mehr ändern kann.

#Fazit

Das Projekt Vector Solutions zeigt, wie eine WordPress-Umsetzung als digitales Rückgrat für ein Technologieunternehmen dienen kann, dessen Käufer nach Spezifikationen entscheiden. Der Wert lag nicht in der Oberfläche, deren Layout ohnehin vom Kunden kam, sondern in einem Content-Modell, das mehrere Produktgenerationen nebeneinander trägt, in Integrationen, die einen Ausfall aushalten, und in einer Cache-Architektur, die mit Personalisierung koexistiert, statt von ihr ausgehebelt zu werden.

Der Kern der Erfahrung aus diesem Projekt lässt sich in einem Satz zusammenfassen: Für ein B2B-Technologieunternehmen ist die Website keine Broschüre, sondern ein Arbeitsmittel, das komplexe Abläufe abbilden, sich in bestehende Systeme einfügen und unter realer Last funktionieren muss. Übertragbar auf ein weiteres Projekt ist die Arbeitsweise, nicht das Content-Modell dieses Kunden: Das entstand für seine Daten, seine Rollen und seinen Katalog, und eine zweite Umsetzung beginnt daher wieder mit einer Analyse des Umfangs.