Das Zeitalter des Onlineshops nähert sich seinem Ende. Es wird mobil, in Apps und quasi überall gekauft: Apple verlegt seinen Shop in die normale Website, jede Menge Plattformen streuen ihre eigenen Buy-Buttons aus, von Facebook über Pinterest bis hin zu Idealo, und zukünftig wird auch in Smartwatches und Smart-TVs gekauft.

Die Folge: E-Commerce-Software verändert sich von der klassischen Shopsoftware zur Transaktionssoftware, die unterschiedliche Kanäle unter einen Hut bekommen muss. Benutzeroberfläche und Kernfunktionalität trennen sich, E-Commerce-Software wird modularer und flexibler. Ein Trend, dem auch ERP- und Warenwirtschaftssysteme folgen.

Genauso wie Konsumenten und ihre Ansprüche an die neue digitale Handelswelt verändern sich auch die Ansprüche der Händler an die Softwarelösungen für den digitalen Handel. Schnelle Änderungen am Geschäftmodell eines Unternehmens oder plötzliche Erfolge und die damit einhergehende stärkere Belastung fordern von Softwarelösungen immer mehr Flexibilität ein. Die klassische Shopsoftware wird mehr und mehr zur „Transaktionssoftware“, abgewickelt werden Abo-Modelle von Einzelprodukten, digitale Dienstleistungen, Software und Käufe aus allen möglichen Quellen: Das Frontend kann dabei ein klassischer Onlineshop sein, genauso aber eine Unternehmenssite, ein Produktkatalog, eine Smartphone-App, eine Social-Network-Plattform, ein Smart-TV oder eine Smartwatch.

Um den aktuellen Softwaremarkt als Entscheider einordnen zu können und informierte Entscheidungen zu treffen, ist es wichtig, zu verstehen, welche Softwarelösung wie viel „Individualität“ bietet. Denn den Trend zur flexibleren und individuellen E-Commerce-Software haben alle Anbieter erkannt, aber unterschiedlich umgesetzt.

Ein Beispiel aus der Praxis: Ein Onlinehändler startet mit einem Shopsystem und nutzt das System als Komplettlösung. Die vorinstallierte Designvorlage, das Shop-Theme, bildet als Frontend die „sichtbare Spitze“ des „Eisbergs Shopsystem“, der Kern des Systems, das Backend, wickelt die Bestellungen ab und die Faktura-Funktion des Shopsystems zeigt die eingegangenen Bestellungen, die ausgedruckt oder versandt werden.

Jetzt passiert dem Onlinehändler etwas erfreuliches: Der Traffic steigt. Leider passiert dem Onlinehändler gleichzeitig etwas weniger erfreuliches: Der Shop lahmt, denn das Frontend ist nicht auf soviel Traffic ausgelegt und die Mitarbeiter kommen nicht mehr mit dem Versand hinterher – denn die Faktura-Funktion des Shopsystems ist nicht auf hunderte Belege pro Minute ausgelegt.

Jetzt muss eine neue Lösung her, aber welche?

Zur Auswahl steht E-Commerce-Software, die sich in drei grobe Kategorien einteilen lässt: Standardsoftware, E-Commerce-Framework und E-Commerce-Plattform. Standardsoftware ist „fertige Software“, sie stellt also einen weit entwickelten Onlineshop mit vielen Funktionalitäten bereit: Herunterladen, auf dem Webserver installieren, Artikel einstellen und der Shop läuft. Oder im Falle einer Standardsoftware als Cloud-Lösung: Registrieren und auf „los“ drücken und der Onlineshop läuft – extrem vereinfacht ausgedrückt.

E-Commerce-Frameworks oder Cloud-Plattformen hingegen sind unterschiedliche Entwicklerwerkzeuge, um einen maßgeschneiderten Onlineshop zu entwickeln. Ein E-Commerce-Framework beginnt auf der untersten Ebene der Anwendungsentwicklung, vergleichbar beispielsweise mit einem klassisches PHP-Framework – nur eben speziell ausgerüstet mit Werkzeugen für den Anwendungsfall E-Commerce. „Fertige“ Funktionalitäten für den Onlineshop gibt es auf dieser Ebene noch nicht, die können flexibel selbst entwickelt werden – genauso, wie sie gebraucht werden. Ein Framework verkürzt im Vergleich zur vollständigen Eigenentwicklung die Entwicklungszeit für eine E-Commerce-Software zwar enorm, ist aber ein wenig zeitintensiver als eine Entwicklung auf Basis einer E-Commerce-Plattform.

Diese beginnt eine Ebene über dem E-Commerce-Framework. Entwickler beginnen hier im Vergleich zum Framework nicht bei null: Es existieren schon grundlegende Funktionalitäten, mit einer simplen Codezeile könnte beispielsweise der Warenkorb aufgerufen werden. Die Plattform stellt dabei neben den Werkzeugen und Funktionalitäten zur Entwicklung auch gleich die Betriebsumgebung zur Verfügung, der entwickelte Onlineshop wird dann auf der Plattform betrieben und gehostet – klassisches Cloud-Computing. Wichtig: Softwareanbieter bezeichnen leider aus Marketinggründen so ziemlich alles als Plattform – auch wenn es sich in Wirklichkeit nur um eine Standardsoftware handelt.

Die verschiedenen Strömungen in der E-Commerce-Softwarelandschaft sind eingerahmt von einem generellen Trend der Modularisierung: Dieser Trend produziert meist eine verteilte Systemlandschaft, in der verschiedene Softwarekomponenten oder Softwarelösungen sich auf einzelne IT-Aufgaben konzentrieren. Wachsen die Anforderungen an eine einzelne IT-Aufgabe, muss so nicht gleich die komplette Softwarelösung gewechselt oder überarbeitet werden.

Die Interoperabilität zwischen Softwarelösungen wird durch automatisierte Schnittstellen (APIs) hergestellt, aber auch innerhalb der Software wird modularisiert: Die serviceorientierte löst die monolithische Systemarchitektur ab [1]. Ein Monolith ist eine Software, die „aus einem Guß“ besteht. Ein Monolith betrachtet zu bewältigende Prozesse im Ganzen, eine serviceorientierte Systemarchitektur teilt den Prozess hingegen in lauter kleine Teil-Prozesse auf und kapselt diese Systembestandteile – eine Modularisierung.

Software, die auf einer serviceorientierten Architektur basiert, erlaubt es beispielsweise, dass Standardsoftware maßgeschneidert wird: Nur die Komponenten, die ein Onlinehändler für sein Geschäftsmodell braucht, werden in eine Softwareinstanz zusammengefasst. So bleibt die Anwendung schlank und performant und der Händler muss nur die tatsächlich genutzten Komponenten der Software bezahlen.

Standardsoftware bleibt die erste Wahl bei einem kleinem Budget, geringen Umsätzen und bei Unternehmen, die keine eigene Entwicklungsmannschaft besitzen: Sie ist schnell einsetzbar und mit dem vergleichsweise geringsten Kostenaufwand umsetzbar.

Klassische Open-Source-Software wie Magento [2], Oxid eShop [3], Shopware [4] oder Prestashop [5] ist soweit modular aufgebaut, dass Frontend und Backend getrennt und Erweiterungen vorgenommen werden können. Dazu lassen sich APIs nutzen, einfache Funktionalitäten werden mit einem Plugin oder Modul per Mausklick hinzugefügt. Komplexere Anforderungen an das Shopsystem können aber unter Umständen einen Eingriff in das Innere des Systems erforden – in den so genannten Core. Ab diesem Moment ist die Überlegung gestattet, entweder die Standardsoftware zu wechseln oder auf eine Plattform oder ein Framework umzusteigen.

Modernere Systemarchitekturen erlauben da eine größere Flexibilität, wie Shopware und Prestashop zeigen. Magento befindet sich mit der Version 2 auf dem Weg in eine modernere Architektur wie auch Oxid eShop.

Modulare Standardsoftware als nächster Schritt zur Individualisierung einer Software bietet verschiedene fertige Softwarekomponenten zum „Zusammenstöpseln“ an. Benötigt der Kunde nur das Warenkorbsystem, aber nicht die Warenwirtschaft des Shopsystems – dann wird die Warenwirtschaft nicht in die fertige Software übernommen.

Modulare Standardsoftware kann gleichzeitig auch flexibel erweiterungsfähig sein: Das als SaaS-Lösung angebotene Shopsystem Websale [6] kann beispielsweise speziell für den Bedarf des Kunden in einer individuellen Software-Instanz zusammengestellt werden, möchte der Kunde noch Eigenentwicklungen einbringen, kann ein gekapseltes Modul in die Softwareinstanz des Kunden eingebunden werden. Dazu steht eine Schnittstelle zur Verfügung, die alle Rückgabewerte des Kernsystems zur Verfügung stellt.

Modulare Standardsoftware ist aktuell meist in der Anschaffung etwas teurer als einfache Standardsoftware, kann aber je nach Preisgestaltung des Herstellers auch günstiger sein: Der auf Multichannel-Vertrieb spezialisierte ERP-Anbieter Plentymarkets [7] berechnet Kunden nur die genutzten Software-Komponenten, auch die neue Version des E-Commerce-ERPs Actindo 2 [8] ist modular auf einer serviceorientierten Systemarchitektur aufgebaut.

Im Gegensatz zur Standardsoftware enthält ein Onlineshop, der auf einer E-Commerce-Plattform entwickelt wurde, keinen aufgeblähten Code: Da der Onlineshop vom Händler beziehungsweise dessen Entwicklungsteam ja maßgeschneidert wird, wird die fertige Software-Instanz auch nur mit den Funktionalitäten aus der Plattform ausgestattet, die der Händler benötigt. Auf der E-Commerce-Plattform Commercetools [9] oder Xsite [10] beispielsweise wählt der Entwickler konfigurierbare Features aus der Plattform aus, kann auf vorbereitete Komponenten, Schnittstellen und Integrationen in Drittsysteme zurückgreifen. Dazu stehen Software Development Kits in unterschiedlichen Sprachen zur Verfügung. Manche E-Commerce-Plattformen wie etwa Commercetools bieten in Zukunft Shop-Gerüste an, die demonstrieren, wie die Funktionalitäten der Plattform eingesetzt werden können – aber unter Umständen auch als funktionsfähiges Template für mittlere Onlinehändler lohnen.

Commercetools realisiert als klassische E-Commerce-Plattform auch ein automatisch skalierbares Hosting, die Cloud-Server werden in Echtzeit an den Traffic angepasst. Commercetools betreibt dabei ein „echtes“ Software-as-a-Service-Abrechnungsmodell: rein nutzungsabhängig, keine Fix- oder Lizenzkosten. Neben Commercetools sind noch weitere Anbieter in diesem Segment tätig, die US-Anbieter Demandware [11], IBM Websphere Commerce [12], Mozu [13] und Wombat [14] und der deutsche Anbieter Xsite bieten vergleichbare Dienste an. Mit Plattformen lässt sich aufgrund der fertigen Funktionalitäten schneller ein fertiger Onlineshop umsetzen als mit einem Framework. Trotzdem sind Projektlaufzeiten zwischen einem und sechs Monaten üblich, die Projektkosten erreichen schnell mindestens einen mittleren fünfstelligen Betrag.

Die Herausforderungen im E-Commerce liegen nicht in der Oberfläche eines Onlineshops begraben, sondern im Backend und in den Prozessen. Händler und E-Commerce-Unternehmen, deren Prozesse vom Standard abweichen, können eine Standardsoftware nicht auf ihre Bedürfnisse anpassen – oder müssen so tief in den Kern der Software eingreifen, dass jede Updatefähigkeit verloren geht. Beispielsweise ein Abo-Commerce-Anbieter, der seine Produkte mit einer eigenen Crowdfunding-Funktion finanzieren und vertreiben möchte – dafür gibt es keine Shopsoftware. Hier heißt es Hemdsärmel hochkrempeln und selbst die Hand anlegen. Für einen solchen Fall ist ein Framework gut geeignet. Vorausgesetzt, die Manpower und der finanzielle Hintergrund sind vorhanden.

Die passende Projektgröße für Frameworks beginnt erst etwa im mittleren fünfstelligen Bereich und kann mindestens sechs bis neun Monate Zeit in Anspruch nehmen. Sowohl Projektdauer als auch Kosten sind höher anzusetzen als in jeder anderen Kategorie. Spryker Systems, ein E-Commerce-Framework, das aus dem Portfolio von Project A Ventures, dem Frühphaseninvestor und Company Builder der Otto Group stammt, beginnt mit runden 100.000 Euro Lizenzkosten und empfiehlt sich selbst ab einem Brutto-Umsatz von etwa 5 Millionen Euro.

Neben Spryker ist noch die französische Open-Source-Lösung Thelia 2 [15] als moderne, zeitgemäße E-Commerce-Framework-Lösung auf Symfonie-2-Basis erwähnenswert.

Was passiert, wenn ursprünglich als E-Commerce-Framework gestartete Lösungen sich über die Jahre hinweg entwickeln, demonstriert die Enterprise-Lösung Hybris [16], die vom Framework zur Komplettlösung mutiert ist. Eine Entwicklung, die potenziell jedes Framework oder auch eine Plattform durchmachen könnte. Den Weg hat auch der Anbieter e:matters [17] hinter sich: Ursprünglich als Agentur mit einem Framework gestartet, haben sich im Laufe der Jahre durch viele Kundenprojekte Funktionalitäten und Module angesammelt, sodass das ursprüngliche Framework zur fertigen Softwarelösung angewachsen ist – und aus der Agentur ein Softwarehersteller wurde.

Da die ursprüngliche Flexibilität durch eine serviceorientierte Architektur, ein E-Commerce-Framework als Grundlage und einen modularen Ansatz noch erhalten ist, stellt e:matters ähnlich wie hybris eine E-Commerce-Komplettlösung mit Framework-Basis dar.

Unabhängig davon, ob klassische Standardsoftware oder eine Plattform als Backend zum Einsatz kommt, gibt es mittlerweile die Möglichkeit, das Frontend unabhängig vom Backend zu entwickeln: Die Systeme werden über eine Schnittstelle verbunden. Ongr.io [18] ist ein solches alleinstehendes Frontend, bestehend aus einem fertigen Gerüst zum schnellen Aufbau einer grafischen Oberfläche. Das Frontend nutzt das PHP-Framework Symfony 2 und eine skalierbare Volltextsuche mit einer hochleistungsfähigen NoSQL-Datenbank namens Elasticsearch. Das Funktionsprinzip ist einfach: Alle Funktionen und Daten, die das angeschlossene Backend zu langsam liefern könnte, wie beispielsweise Produktdaten für die Suche, werden in die schnelle Infrastruktur des Frontends Ongr.io ausgelagert. Die Trennung von Frontend und Backend schafft nicht nur Performance – sollte das Backend ausgetauscht werden, kann das bestehende Frontend einfach an das neue Backend angeschlossen werden.

Das noch recht junge Feld der spezialisierten E-Commerce-Frontends wird im Moment neben dem frei verfügbaren Open-Source-Produkt ongr.io noch von Anbietern wie Amplience [19] bedient.

Die Anforderungen an E-Commerce-Software sind gestiegen, der Markt ist in Bewegung. Unternehmen, die Anwendungen für den Hochlastbetrieb brauchen, können heute die Bestandteile ihrer Systemlandschaft aus vielen Komponenten zusammenstellen – oder sich ihre Komplettlösung aus einer Quelle maßschneidern. Beides hat Vor- und Nachteile: Zu viele Köche verderben den Brei, das kann auch bei Software gelten. Bei unsauberer Umsetzung entstehen auch in der schönen neuen, modularisierten Welt wieder technische Abhängigkeiten, die Updateprobleme nach sich ziehen können. Für Entscheider ist es deshalb wichtig, sicherzustellen, dass E-Commerce-Plattformen oder modulare Standardsoftware so konzipiert sind, dass eine Aktualisierung des Cores, der Kernanwendung, die selbst entwickelten Module, Anbindungen oder Anwendungen nicht beeinträchtigen wird.

Auch wenn für kleine bis mittlere Onlinehändler eine Standardsoftware ausreichend ist, schadet es bei einem geplanten, schnellen Wachstum nicht, die Optionen für eine spätere Skalierung bereits vom Start weg im Auge zu behalten. Oder womöglich gleich einen Schritt größer zu planen: Commercetools beispielsweise bietet in Kürze auch für kleine Projekte ein schnell anpassbares Template, das die wichtigsten Funktionen bereits enthält. Auch Frameworks wie Spryker haben Templates im Portfolio, die den Start etwas erleichtern.

Trotzdem bleibt die Standardsoftware für kleine bis mittlere Onlinehändler die sinnvollste Entscheidung, da für die Entwicklung von eigenen E-Commerce-Anwendungen mit einem E-Commerce-Framework oder einer -Plattform ein eigenes Entwicklerteam, eine längere Entwicklungszeit bis zum Marktstart und ein größeres Budget notwendig sind.