Eine Multisite reduziert die technologische Verschuldung in einer Organisation drastisch

Wenn es darum geht, viele Websites zu erstellen und zu pflegen, haben Unternehmen oft Schwierigkeiten. Mit verschiedenen Anforderungen, Technologien, Agenturen und Standards enden sie oft mit einem massiven technologischen Schuldenberg, der schließlich durch den vollständigen Neuaufbau der Websites beglichen werden muss. Die Anhäufung von Schulden beginnt dann typischerweise von neuem.

Um den endlosen Kreislauf zu durchbrechen, können Unternehmen einen Multisite-Ansatz verwenden, der Standardisierung bringt und den Schuldenstand verringert.

Der Bedarf an vielen Websites

Da das Web immer mehr Kommunikation mit den Zielgruppen des Unternehmens übernimmt, wächst der Bedarf an mehreren Websites.

• Wo Unternehmen früher eine globale Website haben konnten, müssen sie jetzt in der Lage sein, jeden Markt separat anzusprechen.
• Wo sie früher alle Marken auf einer Website listen konnten, müssen sie jetzt eine separate Website pro Marke erstellen, um besser mit jeder Nische kommunizieren zu können.
• Manchmal sind sogar auf der Ebene einer einzelnen Marke mehrere Websites erforderlich:
  • eine für das globale Publikum,
  • und eine andere beispielsweise für einen bestimmten Kundenkreis, der zahlenmäßig gering ist, aber im Umsatz groß,
  • und dann noch eine weitere für eine Veranstaltung oder Konferenz, die die Marke jedes Jahr ausrichtet.

Der Bedarf, mehrere Websites zu erstellen, wächst. Ebenso die Probleme mit der Wartung all der Websites, die erstellt werden. Werfen wir einen Blick auf verschiedene Ansätze, die Unternehmen verfolgen, und was die Ergebnisse sind.

Ein „frei zu bauender“ Ansatz für die Webentwicklung

Der heutzutage häufigste Ansatz für die Webentwicklung besteht darin, jedem Kosten- oder Gewinnbereich zu erlauben, die Websites zu erstellen, die er benötigt, und auf die Weise, die er dafür wünscht. Tiefer in der Organisation, in einem Gewinnbereich, wenn eine Abteilung (typischerweise Marketing, aber es könnte auch andere geben) entscheidet, dass sie eine zusätzliche Website benötigt, ist es ihr freigestellt, zu bauen, was sie will und wie sie es will.

Dieser Ansatz scheint in der Theorie großartig zu sein - diejenigen, die dem Geschäft am nächsten stehen, wissen am besten, was sie brauchen - aber er beginnt wirklich schnell zu schwanken.

Jede Website ist völlig anders

Um eine Website zu erstellen, legt jedes Team eigene Pläne fest, entscheidet, was es will, erstellt Spezifikationen, findet und beauftragt eine Agentur und baut dann die Website damit. Die Technologie, die jede Website antreibt, hängt daher eher von den Fähigkeiten des Teams oder noch wahrscheinlicher von den Fähigkeiten der gewählten Agentur ab:

• einige werden Open-Source sein, einige proprietär,
• einige werden intern gehostet, einige von der Agentur und einige in einer völlig anderen Konfiguration von einem Drittanbieter gehostet.

Abgesehen von den Technologien wird jede Website anders aussehen und ähnliche Anforderungen auf unterschiedliche Weise erfüllen: Zum Beispiel könnte ein Filialfinder einer Marke eine Karte sein, auf der Sie zoomen können, während eine andere Marke Benutzer auffordern könnte, nach Stadt zu filtern.

Jede Website separat zu warten, sind sehr teuer

Die Kosten für den separaten Aufbau jeder Website sind recht hoch und überholen schnell einen Multisite-Ansatz (möglicherweise bereits bei Website 3 oder 4), aber die größten Hürden beginnen, wenn Wartung erforderlich ist.

Wenn jede Website unterschiedlich von verschiedenen Teams erstellt wurde, wird die Wartung ebenfalls von separaten Teams durchgeführt, die in der jeweiligen Technologie qualifiziert sind. Dies ist ein massiver Kostenaufwand.

Lassen Sie uns berechnen:

Wenn ein Unternehmen 50 Websites hat und eine Website ca. 20 Stunden Wartung pro Monat benötigt (das ist sehr wenig für eine größere Website), muss es für 1000 Stunden Wartung jeden Monat!!! bezahlen. Diese Zahl steigt nur, wenn aktive Entwicklungen durchgeführt werden müssen (Features hinzugefügt, Kampagnen gestartet usw.).

Wie gehen Unternehmen damit um? Normalerweise tun sie es nicht...

Die „weniger wichtigen“ Websites werden typischerweise einmal erstellt und dann nie gewartet. Sie bleiben einfach unaktualisiert, was die Frage aufwirft, ob es überhaupt sinnvoll war, sie zu erstellen. Diejenigen, die Wartung benötigen, werden ad-hoc gepflegt.

Mit der Zeit werden die vernachlässigten Websites veraltet. Die Agentur, die sie erstellt hat, ist längst weg, da kein Budget für einen Support-Vertrag vorhanden war. Die Technologie wird veraltet. Sicherheitsexploits werden identifiziert. Schließlich sieht die Website alt aus, und es muss etwas dagegen unternommen werden, da dies schlecht für die Marke ist. Aber niemand weiß, wie man mit dem Legacy-Code-Base umgeht, und jede Agentur empfiehlt den Neuaufbau.

Wenn die Website nicht rechtzeitig neu aufgebaut wird, wird sie typischerweise gehackt. Wenn immer mehr bekannte Exploits gefunden werden, entdeckt schließlich ein oder mehrere automatisierte Bots ein Sicherheitsloch. Die Website wird Teil eines Botnetzes oder beginnt, Bitcoin zu minen oder auf Websites mit Malware umzuleiten. Sie wird dann heruntergenommen und... ja - neu aufgebaut.

Nur um die Hauptwebsites kümmert man sich in einem typischen Unternehmen. Dennoch - jede von einem separaten Team. Wenn das Unternehmen 10 davon hat (z.B. 1 Marke in 10 Ländern), muss es 10 Retainer an 10 separate Agenturen nur für die Wartung zahlen. Wenn eine Website ein neues Feature hinzufügen möchte, muss es den Umfang festlegen, eine Schätzung einholen und dafür bezahlen. Wenn alle Websites dasselbe wollen - müssen die Kosten 10-mal getragen werden.

Das oben Gesagte wird in jedem Profitcenter und jeder Abteilung des Unternehmens jedes Mal separat wiederholt, was massive Kosten und eine Fülle von Technologien und Ansätzen zur Folge hat.

Ein „Richtlinien“-Ansatz zur Webentwicklung

Offensichtlich haben viele Unternehmen erkannt, dass der „Frei zu bauen“-Ansatz nicht optimal ist und versuchen, entgegenzuwirken. Einer der häufigsten Wege dies zu tun, besteht darin, Richtlinien oder Politik zu verwenden.

Das Hauptquartier wird Richtlinien darüber veröffentlichen, „wie wir Websites bauen“ und erwarten, dass alle diese befolgen. Die Policy wird typischerweise Informationen über verwendete Technologien und einige Empfehlungen zur Implementierung auf der technologischen Seite enthalten. Zum Beispiel könnte das Unternehmen verlangen, dass alle Websites auf Drupal gebaut und in AWS gehostet werden.

Die Richtlinien beinhalten immer häufiger Designanforderungen und es muss hier gesagt werden, dass viele Unternehmen wirklich großartige Werkzeuge entwickelt haben, um allen Teams einen standardisierten Ansatz für die visuellen Darstellungen zu ermöglichen. Eine Liste verschiedener Designsysteme ist wirklich beeindruckend.

Richtlinien sind besser, aber nur ein halber Weg

Der Richtlinienansatz ist besser. Er reduziert die technologischen Schulden, die ein Unternehmen trägt. Wenn die Richtlinie befolgt wird, verwendet das Unternehmen nur wenige Technologien und obwohl separate Teams und Agenturen normalerweise die Websites erstellen, können einige Einsparungen erzielt werden:

1. Obwohl es schwierig ist, kann das Unternehmen ein wenig arbitrage betreiben, indem es Kosten zwischen Teams und Agenturen vergleicht. Es kann auch die Qualität der Ausgabe vergleichen.
2. Ein gewisser Code-Wiederverwendung könnte möglich sein, wenn ein Team etwas baut und es mit anderen teilt. Dies wird jedoch nicht immer möglich sein, da trotz derselben Technologie die Websites sich in ihrer Architektur erheblich unterscheiden können.
3. Alle Agenturen, mit denen das Unternehmen zusammenarbeitet, haben Erfahrung mit derselben Technologie, sodass zumindest theoretisch eine Agentur die Arbeit einer anderen übernehmen könnte. In der Praxis ist dies jedoch ziemlich schwierig, da separate Teams meistens nicht kommunizieren, obwohl sie dasselbe tun.

Die Verwendung einer Richtlinie oder Führung ist ein Schritt in die richtige Richtung, jedoch nicht ausreichend, um technologische Schulden effektiv zu verwalten. Wie wir beim Drupal-Beratung für viele Kunden festgestellt haben, bauen Unternehmen immer noch viele Teams, die Dinge vollständig separat erstellen, und Wiederverwendung oder Skaleneffekte sind begrenzt. Die Wartungskosten sinken in der Regel auch nicht sehr stark.

Multisite (eine Codebasis) Ansatz

Der letzte und erfolgreichste Weg, viele Websites zu verwalten, ist der Multisite-Ansatz.

Ein Multisite bedeutet, viele Websites auf derselben Codebasis zu erstellen. Die Idee ist, dass die meisten der Websites, die das Unternehmen erstellt, typischerweise sehr ähnlich sind (z.B. eine Website derselben Marke, aber für mehrere Länder). Wenn wir eine Website einmal erstellen, können wir das, was wir gebaut haben, auf all diesen Websites wiederverwenden, vielleicht nur ein paar Anpassungen hier und da hinzufügen. Wir haben einen separaten Artikel verfasst, der im Detail beschreibt, wie Drupal-Multisite unter der Haube funktioniert.

Der Bau einer Drupal-Multisite erfordert etwas mehr Planung und Disziplin als der Bau einer einzelnen Website, aber die Investition wird schnell amortisiert.

1. Wenn wir eine Vorlage haben, können wir schnell mehrere Websites starten. Keine Notwendigkeit mehr für mehrere Teams, Planungsprozesse usw. und eine separate Agentur für jede Website. Das mehrfach ersparte Geld bei diesem Prozess kann für Wartung, Verbesserungen oder andere Aktivitäten ausgegeben werden, um die Multisite insgesamt zu verbessern.
2. Es gibt nur eine Codebasis, die gepflegt werden muss. Dadurch ist es viel einfacher und günstiger, sie aktuell und sicher zu halten. Ein kleines Team kann den Code für Hunderte von Websites warten. Da es ein Budget verwendet, das ansonsten zwischen vielen separaten Websites geteilt werden müsste, kann es eine viel gezieltere und bessere Arbeit leisten, um hochwertige Lösungen zu liefern.
3. Funktionswiederverwendung ist der Standard. Wenn etwas für eine Website verbessert oder repariert wird, können alle Websites davon profitieren.
4. Falls aus irgendeinem Grund die Codebasis veraltet ist und auf etwas Neues migriert werden muss, wird das Projekt größer, aber wir können eine Website nach der anderen migrieren und dabei ein verbessertes Version an die Websites liefern.

Insgesamt reduziert der Bau einer einzigen Codebasis auf einer Multi-Site drastisch die Menge an Code, die Anzahl der beteiligten Personen und die Wartungsanforderungen. Es stellt sicher, dass alle Websites in der Organisation sicher und auf dem neuesten Stand sind und dass es jemanden gibt, der sie wartet, weiß, wie sie funktionieren, und allen Teams helfen kann, die sie verwenden.

Zusätzlich erhalten wir durch eine Multisite die Standardisierung der Ansätze. Ein Filialfinder kann auf allen Länder gleich funktionieren. Wir können Zeit verbringen, um die besten Lösungen auszuarbeiten und sie dann auf Hunderte von Websites zu übertragen.

Zusammenfassung

Wenn Sie planen, eine Multisite zu erstellen, aber nicht sicher sind, wo Sie anfangen sollen oder ob dies der richtige Ansatz für Ihr Projekt ist, sehen Sie sich unser Drupal Multisite-Angebot an und kontaktieren Sie uns, um über Ihre Anforderungen zu sprechen.