Die 4 häufigsten Bauarten von Webanwendungen

Wenn Web-Apps Autos wären…

Webanwendungen sind überall: Es gibt Webseiten mit viel Information, soziale Netzwerke zum Chatten und Teilen, und Intranet-Anwendungen, die Firmen dabei helfen erfolgreich zu sein.

Doch was steckt eigentlich unter der Motorhaube? Wie werden diese Anwendungen gebaut? Aus was bestehen sie? Und was kosten sie? Ein Überblick.

Von außen ähneln sich alle Bauarten.

Von außen ähneln sich alle Bauarten.

Die vier häufigsten Bauarten sind:

  • From Scratch
  • Library Collection
  • Framework
  • Content Management System (CMS)

Obwohl sie sich von außen ähneln gibt es große Unterschiede im Cockpit, unter der Motorhaube und am Preisschild. Sehen wir uns zuerst die Scratch-Bauart an.

Dieser Artikel als Video:

Entwicklung from Scratch

From Scratch war früher die verbreitetste Bauart. Wer sie verwendet, beginnt ganz von vorne: Beim technischen Plan. Ein Architekt zeichnet alle Komponenten von Grund auf neu und entwickelt sie gemeinsam mit einem großen Experten-Team speziell für die eigenen Wünsche.

Ein technischer Plan im Entstehen…

Ein technischer Plan im Entstehen…

Scratch-Anwender haben auf jeder Ebene spezielle Wünsche, die berücksichtigt werden müssen. Das Konstruieren, das Bauen und das Ausmerzen von Fehlern dauert lange und das Experten-Team ist nicht gerade günstig - aber am Ende steht ein Produkt, das exakt den Vorstellungen und Wünschen des Users entspricht - bis ins kleinste Detail.

Wenn es aber im Betrieb einmal ein Problem gibt, kennt sich auch nur die Werkstatt des Herstellers aus - und die ist wegen dem großen Experten-Team schon mal sehr teuer oder gar ausgebucht.

Fehlersuche unter der Motorhaube

Fehlersuche unter der Motorhaube

Es geht auch einfacher - so lautet zumindest das Motto der Library Collection Entwickler.

Verwendung einer Library Collection

Die haben eine riesige Sammlung an Open Source Komponenten für sich entdeckt, die von vielen Freiwilligen gemeinsam gebaut, optimiert und an interessierte Entwickler verschenkt werden. Einfach so - weil sie damit Endnutzern das Leben erleichtern möchten. Und das ist ihnen gelungen!

Einzelteile im Regallager

Einzelteile im Regallager

Wenn jemand eine Library-Webanwendung in Auftrag gibt, wählt ein Entwickler aus den tausenden vorhandenen Einzelkomponenten jene aus, die die Wünsche der User erfüllen, mit denen er selbst schon einmal gute Erfahrungen gemacht hat, oder die ihm empfohlen wurden. Er vergleicht sie und entscheidet sich dann für einige. Dann setzt er sie so zusammen, dass sie miteinander gut funktionieren und ergänzt, was noch fehlt. Fertig ist die Library-Anwendung!

Erst nach einigen Monaten oder Jahren haben Library-Nutzer manchmal Probleme. Wenn die Anwendung nicht mehr erreichbar ist zum Beispiel. Das kann etwa an der Datenbank liegen, der Serverlast oder einem Hardwaredefekt. Weil die Open Source Komponenten sehr bekannt sind gibt es zwar viele Experten für jede Komponente, aber keinen der sich mit der individuellen Zusammenstellung im jeweiligen Produkt auskennt und alle Zusammenhänge versteht.

Es könnte so einfach sein…

Es könnte so einfach sein…

Fehler zu beheben oder das Produkt weiter zu entwickeln ist schwieriger für jemanden, der nicht genau weiß wie die Teile unter der Motorhaube angeordnet sind und wie sie verbunden sind. Und wenn der Hersteller schon bei der Auswahl der Teile auf das falsche Pferd gesetzt hat, kann es sein dass ein hartnäckiger Fehler - etwa im Kern des Produkts - von den freiwilligen Machern der Komponente überhaupt nie behoben wird. Und da kommt die Framework-Bauweise ins Spiel.

Frameworks und die 80/20-Regel

Framework-Apps bestehen auch großteils aus Open Source Komponenten. Der Unterschied liegt in der Auswahl und Kombination der Teile. Und das geht so: Die Community der Hersteller tauscht sich laufend über Produkte und Komponenten aus und vergleicht sie und jeder berichtet von den eigenen Erfahrungen.

Im Laufe der Zeit haben die Hersteller gemerkt, dass die Endprodukte sich zwar für Benutzer stark unterschieden, gewisse technische Details aber meistens gleich sind - nämlich ca. 80 Prozent. Deshalb hat die Community sich entschieden regelmäßig ein 80-Prozent-Produkt zu bauen und auch als Open Source Lösung anzubieten, ein Framework.

Ein 80% Rohbau

Ein 80% Rohbau

Framework-App Hersteller nehmen dieses 80-Prozent-Produkt als Grundlage für jedes Projekt und fügen dann die 20 Prozent hinzu, die den individuellen Wünschen entsprechen. Alle Komponenten sind in einheitlicher Form kombiniert und oft austauschbar. Die Konventionen ändern sich zwar hin und wieder aber jeder der sie kennt kann Framework-Anwendungen warten und verbessern, auch wenn die Entwicklung schon einige Jahre zurück liegt.

Best Practice Beschriftungen & Co.

Best Practice Beschriftungen & Co.

Content Management Systeme: 100% und mehr?

Einige Mitglieder der Open Source Community bauen nicht nur 80-Prozent-Produkte sondern 100% einsatzfertige Anwendungen und stellen sie kostenlos jedem zur Verfügung. Das sind Allround-Anwendungen, die oft nur noch an das Wunsch-Design angepasst werden müssen.

Damit sie von möglichst vielen Benutzern verwendet werden können sind Content Management Systeme meist von Haus aus mit sehr vielen Funktionen ausgestattet. Um ein CMS für Benutzer einfach bedienbar zu machen müssen Entwickler oft Funktionen noch deaktivieren oder deren Einstellungen detailliert anpassen. Tun sie das nicht, ist das Endprodukt oft überladen und schwerfällig.

Cockpit: Flugzeug oder Auto?

Cockpit: Flugzeug oder Auto?

Spezielle Wünsche, die noch nicht enthalten sind, sind in Content Management Systemen manchmal schwieriger zu ergänzen.

Fazit: Welche Bauart für das eigene Projekt?

Verschiedene Bauarten führen zum Ziel: Scratch-Anwendungen bauen alles von Grund auf neu, Library Collection-Apps verwenden Open Source Einzelkomponenten, Framework-Apps basieren auf erweiterbaren Rohbauten und Content Management Systeme sind Allround-Lösungen für die häufigsten Nutzerwünsche.

Die Auswahl der richtigen Bauweise ist die erste technische Entscheidung bei jedem Projekt. Die gewählte Bauweise hat einen wesentlichen Einfluss auf die Time-To-Market (TTM), die Erweiterbarkeit, Wartbarkeit, Kosten und mögliche Folgekosten.

Benjamin Groessing

Benjamin ist Web-Entwickler und Gründer von BYTEQ und hat schon unter so manche Webapp-Motorhaube geblickt. Am liebsten unter die von Frameworks und CMSen. Mehr…

Neuigkeiten per Email?
Kein Spam. Jederzeit abmeldbar.

Einhorn, das weiß wie man BYTEQ ausspricht