Wie Sie Ihr nächstes Webprojekt (nicht) organisieren sollten

Warum Sie sich Gedanken darüber machen sollten, wie Sie Ihre Frontend-Entwicklungsteams und Plattformintegrationsteams organisieren, welche Auswirkungen unterschiedliche Ansätze dabei haben und wie sich dies auf Ihr Webentwicklungsprojekt auswirkt.

Heutzutage gibt es wahrscheinlich nur wenige, die wir von der Bedeutung eines modernen, leistungsfähigen Frontends für die Qualität und den Gesamteindruck einer Website überzeugen müssen. Gleichzeitig sollte es mittlerweile auch allgemein bekannt sein, dass eine horizontale Aufteilung Ihrer Entwicklung (in unserem Fall Frontend und Backend) und das völlig unabhängige Bereitstellen dieser Layers kaum zu guten Ergebnissen führen wird. Was aber ist dann der effektivste Organisationsansatz?

Nehmen wir an, es ist an der Zeit, eine neues Webprojekt oder einen Relaunch umzusetzen. Sie haben bereits die richtige zugrunde liegende Plattform (E-Commerce- oder Content-Management-Lösung) ausgewählt, die alle Anforderungen des 21. Jahrhunderts erfüllt. Alles ist gut geplant und jetzt müssen Sie nur noch sicherstellen, dass Ihr eigentliches Projekt erfolgreich umgesetzt wird. Glücklicherweise haben Sie bereits das Team mit der Plattform Ihrer Wahl beauftragt − also sollte alles reibungslos funktionieren, richtig?

Einen Moment! Wie sieht es mit der Umsetzung des Frontend-Teils Ihres Projekts aus? Alle diese schicken, durchdachten Designs müssen in ein leistungsfähiges Trio aus HTML, CSS und JS übersetzt werden. Es besteht die Möglichkeit, dass Sie in die Versuchung geraten, ein separates Team dafür zu wählen—sei es, um die Abhängigkeit von einzelnen Dienstleistern zu vermeiden oder weil Sie bereits eine separate Kreativagentur ausgewählt haben, die Ihnen natürlich auch die Frontendentwicklung mit anbietet. Schließlich ist Frontend-Technologie heutzutage doch ziemlich standardisiert und es sollte für andere Entwickler keine Probleme geben, mit fremdem Code zu arbeiten, oder? Die kurze Antwort lautet: Nein.

Unserer Erfahrung nach ist das eine ziemlich schlechte Idee (wir haben das mehr als einmal auf Dienstleisterseite durchlebt). Dies führt am Ende fast immer zu einem höheren Aufwand (und natürlich entsprechenden Kosten) oder zu einer geringeren Qualität—oder (in den meisten Fällen) sogar zu beidem. Lassen Sie und über einige der Gründe dafür sprechen:

• Plattformen haben ihre eigenen Besonderheiten und sind nicht wirklich agnostisch in Bezug auf das Frontend (bzw. die Technologie dahinter).

• Unabhängigen Frontend-Entwicklern fehlt ganz einfach der Kontext, in dem der Code eingesetzt wird.

• Die API zwischen Backend und Frontend ist oft nicht klar definiert, normalerweise im Detail projektspezifisch oder allgemein plattformspezifisch und kann sich laufend ändern.

• Dazu kommen dann noch die üblichen organisatorischen Probleme, die durchaus nicht unüblich sind, aber ebenso oft trotzden nicht wirklich adressiert werden—wie unscharfe Verantwortlichkeit der Projektbeteiligten (besonders wenn Nicht-Techniker technische Teams voneinande abgrenzen sollen), Kommunikationsaufwand, Unterschiede in den Coding-Standards und vieles mehr.

Auch wenn Plattformanbieter häufig versuchen, eine freie Wahl bei der Verwendung bevorzugter Frontend-Frameworks (oder sogar beim gesamten Frontend-Ansatz − indem Sie eine Headless-API anbieten) anzubieten, bleibt immer noch die grundlegende Frage, wie Ihr Frontend am einfachsten in die Plattform integriert werden kann. Ja, ich sage bewusst 'integrieren', da das Frontend in den meisten Fällen nicht nur dafür verantwortlich ist, einfach nur Information 1:1 anzuzeigen, die von der Plattform Ihrer Wahl bereitgestellt wird. Lassen Sie mich anhand einiger Beispiele erläutern, was ich meine. Ihre Redaktionsumgebung bietet höchstwahrscheinlich Mechanismen und Tools, mit denen Editoren Seiten, die aus wiederverwendbaren Funktionsblöcken bestehen, mehr oder weniger frei erstellen können, und sich auf den Aufruf dieser Komponenten einigen können. Sie werden oft automatisch von zusätzlichen HTML-Containern umgeben, die für die Darstellung im Bearbeitungsmodus erforderlich sind. Dies kann bedeuten, dass HTML-Tags hinzugefügt werden, die Ihre Stylesheet-Logik zerstören und damit zu einer fehlerhaften Anzeige der Seite führen. Ein anderes Beispiel: Sie optimieren den Inhalt im visuellen Bearbeitungsmodus der Redaktionsplattform. Sobald Sie die Eigenschaften nur einer einzigen Komponente geändert haben, könnten Sie eigentlich erwarten, dass nur dieser Teil Ihrer Webseite tatsächlich aktualisiert werden muss (diese eine Komponente). Wenn Ihre Komponente jedoch "dynamisch" ist und JavaScript-Ereignisse nutzt, um zu Beispiel sicherzustellen, dass die Seite vollständig geladen ist, wird sie im Bearbeitungsmodus falsch angezeigt werden, da das Ereignis "onLoad" ganz einfach nicht ausgelöst wird. Alle diese Probleme führen dazu, dass im Bearbeitungsmodus oft kleinere Probleme bis hin zu völlig unbrauchbaren Seiten auftreten.

Frontend-Entwickler können Designs problemlos über einen Browser (oder einen gut aussehenden Clickdummy) in ein scheinbar direkt auslieferbares Produkt übersetzen. Das Problem ist, dass es fast unmöglich ist, alle möglichen Fälle für beispielsweise Produkt-Detailseiten zu entwerfen (stellen Sie sich die Anzahl der Kombinationen von Produktnamen, allgemeinen Informationen, Merkmalslisten und mit einem Produkt, einer Produktgalerie usw. verknüpften Marketingmaterialien vor). Das bedeutet, dass Frontend-Entwickler immer nur mit einer sehr kleinen Teilmenge realer Inhalte (Kombinationen) Ihrer Website arbeiten. Speziell bei größeren Websites ist dies ein echtes Problem. Wenn nicht detailliert über die Elemente kommuniziert wird, die später in Varianten zum Einsatz kommen oder neu kombiniert werden, besteht eine sehr hohe Chance, dass viele Werte hardcoded werden oder ihren auf eine Weise gestaltet sind, die später die erforderliche Rekombination unmöglich machen. Je mehr Informationen über die vorgesehene Nutzung des Frontends an das Frontend-Entwicklungsteam weitergegeben werden, desto weniger Arbeit wird dieses Problem später verursachen. Ein weiteres Beispiel aus der Praxis: Angenommen, Sie haben vergessen, gegenüber den Frontend-Entwicklern der Kreativagentur zu erwähnen, dass Sie nicht nur Entwürfe 1:1 implementieren und eine Wiederverwendung oder Re-Kombination in Betracht ziehen, dann haben sie möglicherweise Probleme dabei, eine Akkordeon-Komponente zweimal auf einer Seite einzusetzen. Wir haben Implementierungen gesehen, bei denen Sie durch Anklicken des ersten Elements eines Akkordeons die ersten Elemente aller Akkordeonkomponenten auf dieser Seite erweitert haben. Angenommen, Sie behaupten nun, dass ein separates Team von Frontend-Entwicklern nur das Aussehen (HTML und CSS) und nicht notwendigerweise die Frontend-Logik einer Website implementieren kann, ist dieser Problembereich wohl immer noch gültig. Außerdem würden wir dann eben nicht ein vollständig implementiertes Frontend erhalten. Und ein letztes Beispiel, das in die gleiche Kategorie fällt: Wenn Sie vergessen, diese Information explizit an Ihre Frontend-Entwickler weiterzugeben, kommt es ziemlich sicher zu Problemen bei der Umsetzung von Sprachvarianten Ihrer Website. Ein andwerwertig gutes UX/UI Design wird am Ende vielleicht sogar regelrecht zerstört (z.B. basierend auf unterschiedlichen Wortlängen je nach Sprache) und ein Großteil des Fronted-Codes muss dann einem aufwendingen und teuren Refactoring unterzogen werden, um die Unterstützung für mehrere Sprachen hinzuzufügen.

Es ist wirklich verlockend, Frontend-und Backend-Entwicklung voneinander zu trennen − und es gibt sicherlich Projekte, bei denen das auch möglich und sinnvoll ist. Bei Projekten, die auf den gängigen E-Commerce- oder Content-Management-Plattformen aufsetzen, ist das jedoch kaum der Fall. Unserer Erfahrung nach ist die API zwischen Frontend und Backend in den meisten der etablierten unternehmensorientieren Plattformen ausschließlich in Bezug auf HTML, CSS und JS definiert. Das Ändern eines dieser Elemente wirkt sich damit sehr wahrscheinlich auch auf die Integration aus. Warum ist das wichtig? Am wichtigsten insofern, als dass Sie das HTML, welches von einem (separaten) Frontend-Entwicklungsteam erstellt wurde, nicht einfach in Ihr Plattformprojekt übernehmen können. Dort gibt es sehr wahrscheinlich eine (hoffentlich nicht zu proprietäre) systemspezifische Templating Engine, die mit der Plattform kommt und die letztzlich die von den Editoren gepflegten Daten in HTML umwandelt. Da Frontend-Entwickler häufig keinen direkten Entwicklungszugriff auf die Plattform haben, werden diese Teile normalerweise von Backend-/Plattform-Entwicklern ausgeführt. Stellen Sie sich jetzt eine lange Liste von Änderungen (Change Requests, Bug Fixes) vor, die von Frontend-Entwicklern (in HTML, CSS und JS) angewendet wurden. Sobald die Änderungen implementiert sind, müssen die Plattformentwickler diese Änderungen auch auf alle Templates und Komponenten anwenden. Unserer Erfahrung nach ist dieser Schritt einer der fehleranfälligsten Teile des gesamten Prozesses. Es ist sehr einfach, nur ein zusätzliches Attribut zu übersehen, das vom Frontend-Team hinzugefügt wurde, oder etwa eine leicht geänderte Reihenfolge von HTML-Elementen zu übersehen. Und es ist für den Fachbereich extrem frustrierend − vor allem dann, wenn die Frontend-Entwickler es geschafft haben, ihren Teil in Ordnung zu bringen, aber der aufgrund eines kleinen Templatefehlers immer noch in der Produktions-Website auftaucht. Versionssysteme wie Git lösen dieses Problem leider auch nicht wirklich. Sie machen es sicherlich einfacher, den Umfang etwaiger Änderungen zu verstehen, aber da der Frontend-Code durch die prinzipielle Trennung ja dupliziert ist, funktioniert der ein automatisiertes Zusammenfügen von Änderungen nicht wirklich darüber hinaus − Plattformentwickler müssen deshalb oft jede Änderung manuell und einzeln in ihrem Code-Teil nachziehen.

Wir empfehlen Ihnen zuallererst dringend, Ihr Projekt nicht in Phasen umzusetzen, in denen ein angeblich fertiggestellter Teil eines Systems (Backend/Plattform-Integration) einem anderen (Frontend) folgt. Keiner der fertiggestellten Teile kann im Allgemeinen nämlich als simple Plug-In-Lösung für den anderen genutzt werden, selbst unter den idealen Bedingungen ohne jegliche Change Requests (was mangels detaillierter Spezifikationsdokumentation auch wirklich unwahrscheinlicher denn je ist). Es müssen heutzutage wohl immer Änderungen vorgenommen werden, damit das ein Produkt oder eine Lösung am Ende auch wirklich funktioniert (technisch, funktionell und visuell) und zum echten Kundenerlebnis wird. Darüber hinaus führt die sequentielle Ausführung der Frontend- und Backend-Arbeit dazu, dass das Gesamtsystem unbrauchbar bleibt, bis der andere Teil fertig ist. Es verschiebt damit auch nicht nur einen 'Go Live" in die Zukunft, sondern macht es auch schwierig, Prioritäten über ein gesamtes Projekt hinweg zu setzen und laufend zu aktualiseren, da jeder Teil ja in sich mehr oder weniger abgeschlossen ist. Erwähnenswert ist auch, dass die Arbeit zuerst am Frontend und danach am Backend (oder umgekehrt) weiter von der Gedankenwelt agiler Arbeitsmethode nicht sein könnte. Falls Sie erwägen, dass Ihr Projekt Scrum (oder einem anderen agilen Framework) folgen soll, ist jeder Ansatz, der eine Trennung von Frontend- und Backend-Entwicklung vorsieht, eindeutig vom Tisch.

Was ist also von einem Ansatz von Frontend-Entwicklung (z.B. bei der Erstellung eines statischen Klick-Dummy) zuerst und Backend-Entwicklung danach zu erwarten?

• Lange Diskussionen und Modifikationen des Frontend-Codes, bevor das Backend-Team die vom Frontend-Team geleistete Arbeit im Backend-System auch wirklich übernehmen kann.

• Probleme bei der Umsetzung jeglicher Art von Änderungen − sie müssen ja von beiden Teams verarbeitet und möglicherweise in zwei völlig unterschiedliche Code-Basen eingeführt werden (Frontend-Code wird für die Klick-Dummy- und die tatsächlichen Templates der Content- oder Commerce-Plattform dupliziert)

• Unklare Verantwortlichkeiten bei der Fehlerbehebung: Falls etwas nicht im statischen Klick-Dummy enthalten ist, sich jedoch als Frontend-Fehler herausstellt, welches Team ist dann für die Behebung des Problems verantwortlich? Und dann denken Sie natürlich auch noch daran, dass Bugfixes auch Änderungen sind (siehe vorheriger Punkt).

Es ist auch nicht so, dass der Ansatz 'Frontend zuerst' der einzige problematische Ansatz ist − auch eine vorherige Erstellung des Backends ist überaus problematisch. Das wichtigste Problem ist dabei sicherlich das Fehlen jeglicher (sinnvoller) visueller Darstellung − und das für eine lange Zeit im Projekt. Dies kann für den Fachbereich, der den Fortschritt der Implementierung sehen möchten, wirklich nervenaufreibend sein. Da größere E-Commerce- oder Content-Management-Implementierungen in der Regel doch einiges an Zeit in Anspruch nehmen, kann es dabei auch extrem schwierig werden, zu entscheiden, wann genau man mit der Arbeit an Backend Features aufhört und zur Frontend-Entwicklung übergeht.

Selbst wenn Sie dafür entscheiden, dass Ihre Frontend- und Backend-Teams gemeinsam arbeiten, gibt es noch einige organisatorische Herausforderungen zu meistern. Zuallererst die Kommunikation zwischen den Teams. Sie müssten unbedingt eine einfache und produktive Art der Zusammenarbeit definieren. Darüber hinaus legt unsere Erfahrung einen weiteren Schlüsselfaktor für eine erfolgreiche Zusammenarbeit der Teams nahe. Die Teams sollten sich unbedingt auf einem ähnlichen technischen Niveau befinden, um Probleme, Vorschläge und Lösungen leicht zu kommunizieren und zu verstehen. Um ein Team-Setup effektiv zu gestalten, sollten Sie einen klaren Workflow zwischen Frontend- und Backend-Teams definieren, der gewährleistet, dass Änderungen schnell eingeführt werden können und Doppelarbeit zwischen den Teams minimiert wird.

Das völlig unabhängige Arbeiten am Backend-Code und auf dem Presentation Layer (z.B. indem zwei Dienstanbieter sich darauf unabängig konzentrieren) ist schwierig. Es kann auch Vorteile eines solchen Ansatzes geben, aber die Nachteile überwiegen im Allgemeinen bei weitem. Wir empfehlen Ihnen, diesen Ansatz gänzlich zu vermeiden, im Sinne des Erfolgs Ihres Projekt und für eine möglichst reibungslose Durchführung während des Projekts.

Hier sind 3 Prämissen, die diesbezüglich zu einem erfolgreicheren Projekt führen können. Diese Checkliste ist als Hilfe gedacht und uns ist natürlich klar, dass nicht jedes Projekt gleich ist.

• Stellen Sie sicher, dass der für die Implementierung Ihrer E-Commerce- oder Content-Management-Lösung verantwortliche Servicepartner über ein kompetentes Frontend-Entwicklungsteam verfügt. Mit Kompetenz meinen wir, dass der Partner wirklich in der Lage ist, erfolgreiche digitale Kundenerlebnisse zu liefern, die diesen Namen auch verdienen. Ein Partner, der auf dem neuesten Stand der neuesten (auch bewährten) Web-Technologien ist diese auch in relevanten Projekten in der Praxis einsetzen kann. Alle anderen Kriterien verblassen aus unserer Sicht auch gegenüber diesem einen Kriterium.

• Wenn Sie such—aus welchen Gründen auch immer − doch für unabhängige Frontend- und Plattformintegrations-Teams entscheiden (müssen), stellen Sie sicher, dass Ihre Plattform- und Frontend-Teams kompatibel miteinander sind und am Ende als ein Team auf ein gemeinsames Ziel hinarbeiten können, anstatt unabhängig voneinander arbeitender Parteien. Vor einer Backend-Entwicklungsphase sollte es keine Frontend-Entwicklungsphase geben. Die Teams sollten parallel arbeiten und ihre Arbeit sofort evaluieren und integrieren. Es kann durchaus etwas Zeit kosten, die Teams zu einer produktiven Zusammenarbeit zu bewegen, aber es ist den Aufwand auf jeden Fall wert, wenn Sie schon in diesem Setup arbeiten wollen oder müssen.

• Stellen Sie sicher, dass die Schnittstelle zwischen Frontend und Backend für alle am Gesamtprojekt Beteiligten klar definiert ist. Dies ist ein Hauptfaktor in Bezug auf die Produktivität. Idealerweise können Backend- und Frontend-Teams Daten austauschen, die einem vereinbarten Schema entsprechen. Auf diese Weise konzentrieren sich Backend-Entwickler auf die Erweiterung der Plattform und machen die vereinbarten Daten verfügbar, die zur Erstellung der Benutzeroberfläche im Frontend-Teil des Teams benötigt werden. Eine Möglichkeit ist auch, auf Basis von REST oder GraphQL als API zu arbeiten. Durch die Verwendung solcher APIs gewinnen Sie im Vergleich zum klassischen HTML-Templating-Ansatz viel und das auch schnell. Außerdem können Sie von einigen nützlichen Tools zum Lernen, Dokumentieren und Testen von APIs profitieren - Swagger, Postman oder GraphiQL um nur ein paar zu nennen.

Wenn Sie mehr zu diesem Thema erfahren möchten − bessere Schnittstellen und somit eine bessere Zusammenarbeit zwischen Frontend- und Backend-Entwicklung in E-Commerce- und Content-Management-Projekten − bleiben Sie dran!