Was Spryker und Siroop aus Swisscom-Sicht spannend macht

Siroop, das erste Spryker-Projekt in freier Wildbahn („Was die Spryker/Siroop-Kombination so spektakulär macht„), ist nicht nur aus Coop-Sicht spannend („Siroop und die Online-Ambitionen der Schweizer Coop-Gruppe„).

Mindestens so hilfreich ist es, die Potenziale auch mal aus Swisscom-Sicht zu betrachten („Die Swisscom und ihre neuen Plattform-Potentiale“):

siroop

„Wenn wir also diese Plattformen nicht für sich alleine und nebeneinander existierend, sondern als sich überlappende Modelle betrachten, dann ist es sehr offensichtlich, welche Möglichkeiten sich auch diesen Schnittstellen ergeben könnten. Natürlich immer vorausgesetzt, ein Siroop wird seine Rolle wie geplant einnehmen können (Dauern wird dies auf jeden Fall noch eine Weile).

Die Synergien zwischen den einzelnen Plattformen könnten sehr mächtig und vielschichtig werden:

  • Unternehmenstransaktionen und Zahlungsströme (von allen an den 3 Plattformen involvierten Unternehmen) werden von Conextrade organisiert.
  • Der Weg zum Endkunden auf der Siroop Seite kann ermöglicht und gesteuert werden
  • und alle können auf Dienstleistungen, Support & Services von Mila zurückgreifen.

Da können sehr starke Synergien und Plattform- und Netzwerkeffekte entstehen. Aber für diese Netzwerkeffekte müsste Siroop oder gar noch eine weitere Plattform oder Service noch stärker eine Social-DNA in solch ein Konstrukt bringen.

Aber auch schon so kann man sich in verschiedensten Facetten ausmalen, welche spannende Themen im roten „?“ so alles entstehen könnten. Nicht nur dort, schon die einfachen Schnittstellen bieten grosse Potentiale.“

Mehr dazu im E-Commerce-Blog von Carpathia („In neuen Modellen denken ist gefragt!“) und dann sicherlich auch am 11. Mai auf der E-Commerce Connect in Zürich.

Frühere Beiträge zum Thema:



Kategorien:Shoptech

13 replies

  1. Wobei Spryker als System austauschbar ist und nicht elementar ist. Verstehe daher gar nicht warum Du Spryker so pusht. Hatte mich schon beim ersten Posting gewundert.

    • ob Spryker bei dem Projekt elementar war/ist, wird man erst hinterher wissen … und wenn nicht, könnte man sich ja fragen, warum sich Coop/Swisscom dann überhaupt auf Spryker einlassen …

      Von „pushen“ würde ich bei Spryker auch nicht sprechen. Spryker steht hier im Blog vor allem deswegen im Fokus, weil es andere Wege geht, andere Märkte/Marktteilnnehmer anspricht (und dabei vergleichsweise offen kommuniziert). Entsprechend gut kann man verfolgen, was Wachstumslösungen für den Handel von morgen bringen.

  2. Es wäre auch mal spannend mehr über den ECHTEN erste Onlineshop von Spryker zu erfahren, welcher nach sechs Monaten Arbeit wieder eingestampft wurde / nie das Licht der Welt erblickte. Da könnte man vielleicht wirklich etwas lernen…

  3. Es wurde 5-10 Monate versucht die kartenmacherei.de auf Spryker zu bringen, bis alle Beteiligten aufgrund der vielen Fehler entnervt aufgegeben haben.
    Es wäre doch mal spannnend auch von gescheiterten Projekten zu lernen.
    @Jochen: Hat dir Alexander Graf davon nicht berichtet?

    • Alexander Graf bzw. das Spryker-Team hat mir bisher noch von keinem ihrer Projekte erzählt, auch nicht von Siroop …

      Es ist ja nicht so, dass Alex (oder irgendwer) sagt: „Lieber Jochen, promote doch mal bitte Spryker ein bisschen.“ So läuft das ja nicht. Eher im Gegenteil: Aus den Projektteams dringt in solch frühen Phasen so gut wie gar nichts nach außen. Dass ich auf Siroop als Spryker-Projekt gestoßen bin, war reiner Zufall. Und ich fands spannend genug, um darüber zu schreiben.

      Deshalb auch vielen Dank für den Hinweis mit der Kartenmacherei! Das ist natürlich gut zu wissen …

  4. Spryker ist nicht wirklich innovativ aus meiner Sicht. Eine Shop-Plattform mit PHP und MySQL zu bauen, das ist etwas, das Fabian Wesner schon seit 2010 macht und ich sehe keinen wirklichen technischen Fortschritt.

    – Module, die später individuell erweitert werden können: eine Idee die von Magento kommt und die massives Customizing anregt, was dafür sorgt, dass spätere Core Updates sehr schwer werden.

    – PHP: bis zu einem gewissen Grad skalierbar, später muss alles durch Java / Scala / Go replaced werden. PHP7 wird das Problem auch nur bis zu einem gewissen Grad lösen, weil es keine Threads / Concurrency bietet, was aber bei den „Category Leadern“ ab einem gewissen Punkt wichtig wird.

    – MySQL: vermutlich wieder logisch getrennte Datenbanken, die auch nur bis zu einem gewissen Grad skalieren. Später ein Wechsel auf NoSQL unvermeidlich.

    – Zed Backend: monolithisches Backend, am Anfang sinnvoll, später ein technisches Fass. Gerne auch mal den sehr guten Artikel von Martin Fowler lesen: http://martinfowler.com/bliki/MonolithFirst.html.

    – Open Source: Magento ist vorallem erfolgreich, weil es Open Source ist. Entwickler können Module programmieren und zur Verfügung stellen, die für die Community sinnvoll sein könnten. Auch können Bugfixes submitted werden. Open Source wird immer für mehr Qualität und volatilität sorgen. Wenn ich bspw. für Magento ein Modul für Vorkasse brauche, dann ist die Wahrscheinlichkeit schon groß, dass es Module dazu gibt.

    – Trends: Themen wie AWS Cloud, Data Lakes, Microservices, NoSQL verpasst.

    – Startpaket: laut diesem Video bekommt man ein sehr gutes Startpackage, um zu customizen. Ich sehe hier keinen Vorteil ggü. Magento: https://www.youtube.com/watch?v=VTfg_N9fmKA.

    – Bezug auf Rocket-Internet: https://excitingcommerce.de/2015/07/22/skyrocket-rocket-internet-prasentiert-neue-techplattform/ => RI geht von Bob & Alice weg und baut neue Skyrocket Plattform.

  5. Hallo Peter, ich möchte Dir gerne direkt zu Deinen technischen Anmerkungen antworten. Tatsächlich arbeite ich schon seit 2009 an Shop-Plattformen :-)

    „– Module, die später individuell erweitert werden können: eine Idee die von Magento kommt und die massives Customizing anregt, was dafür sorgt, dass spätere Core Updates sehr schwer werden.“

    Module sind ja total normal in erweiterbarer Software. Ob man später Probleme mit Updates bekommt, hängt von der Art und Weise ab, wie die Erweiterungsmechanismen angelegt sind und wie umfangreich die Aufbauten sind. Die Bundles in Spryker sind maximal entkoppelt, so dass man sie auch einzeln austauschen oder erweitern kann. Die Erweiterung kann per Plugins oder Decorator-Pattern erfolgen. Beides ist recht stabil bei Updates.

    „– PHP: bis zu einem gewissen Grad skalierbar, später muss alles durch Java / Scala / Go replaced werden. PHP7 wird das Problem auch nur bis zu einem gewissen Grad lösen, weil es keine Threads / Concurrency bietet, was aber bei den “Category Leadern” ab einem gewissen Punkt wichtig wird.“

    Skalierbarkeit ist keine Eigenschaft einer Programmiersprache, sondern einer Architektur. Spryker ist schon durch die strikte Trennung in Frontend und Backend sehr skalierbar. Performance ist hingegen durchaus eine Frage der Programmiersprache. Hier ist es so, dass PHP7 ca. doppelt so schnell ist wie PHP5.6. Man könnte den Shop z.B. mit C noch schneller hinbekommen, aber das ist gar nicht nötig. Für den Kunden spielt es ja keine Rolle ob die Server-seitige Ausführungszeit 20 oder 50ms ist und man kann so oder so mit relativ wenigen Servern hohen Traffic bewältigen.
    Threads machen in einer Webseite nicht viel Sinn, da die Lebensdauer eh sehr kurz ist. Daher gibt es sie in PHP auch nicht. Falls man sie dennoch braucht (z.B. für Big data processing), dann kann man ja einen separaten Service in Java entwickeln.

    „– MySQL: vermutlich wieder logisch getrennte Datenbanken, die auch nur bis zu einem gewissen Grad skalieren. Später ein Wechsel auf NoSQL unvermeidlich.“

    Der Spryker-Demoshop wird per-default auf PostgresSQL ausgeliefert. MySQL wird alternativ voll unterstützt. Oracle, MSSQL und SQLite sind auch möglich. NoSQL wird ja im Frontend verwendet (Redis) aber damit kann man keine relationale Datenbank sinnvoll abbilden mit ACID Eigenschaften und abgesicherter Datenintegrität. Von einer fehlenden Skalierbarkeit von SQL-Datenbanken weiß ich nichts, jedenfalls nicht im E-Commerce, man hat ja selten Terabyte an Bestellungen oder Kundendaten. Und größere Datenmengen wie Logfiles gehören da eh nicht rein.

    „– Zed Backend: monolithisches Backend, am Anfang sinnvoll, später ein technisches Fass. Gerne auch mal den sehr guten Artikel von Martin Fowler lesen: http://martinfowler.com/bliki/MonolithFirst.html.“

    Ich halte Microservices nur für sinnvoll, wenn man die Services vollständig isolieren kann inklusive der Datenpersistenz. Das ist bei einem Shop jedoch nicht das Fall, da die Tabellen ja alle per Relationen miteinander verbunden sind und man Modul-übergreifende Joins machen möchte. Man kann das alles schon irgendwie mit Services lösen, aber nur mit viel Overhead und zusätzlicher Komplexität. Meines Erachtens ist ein modularer Monolith für die zentralen Funktionalitäten des Shopsystems die bessere architektonische Entscheidung. Es ist einfach viel übersichtlicher und einfacher in der Entwicklung. Es spricht ja zudem nichts dagegen entkoppelte Erweiterungen separat als Services umzusetzen (z.B. ein PIM).

    „– Trends: Themen wie AWS Cloud, Data Lakes, Microservices, NoSQL verpasst.“

    AWS Cloud ist eine Frage des Hostings, hat mit dem Framework nicht direkt was zu tun. Einen Data Lake (bzw. Full Take Logger) haben wir an Bord. NoSQL ist auch drin (Redis).

    „– Startpaket: laut diesem Video bekommt man ein sehr gutes Startpackage, um zu customizen. Ich sehe hier keinen Vorteil ggü. Magento“

    Spryker ist als Framework konzipiert. Magento ist als fertiges Shop-System konzipiert, Spryker als Framework. Am Ende des Tages werden Entwicklerteams mit Spryker schneller programmieren. Warum das so ist lässt sich kaum in nicht-technischen Worten erklären, Interessenten sollten es einfach mal ausprobieren und vergleichen. Stichwort ist SOLID.

    „– Bezug auf Rocket-Internet => RI geht von Bob & Alice weg und baut neue Skyrocket Plattform.“

    Ich hatte 2011 als CTO von Rocket mit dem Team diverse Shops auf Basis von Alice&Bob gelauncht. Danach wurden noch diverse weitere Shops damit umgesetzt, aber inzwischen macht Rocket ja eher weniger E-Commerce, so dass die Weiterentwicklung wenig sinnvoll wäre. Christians SkyRocket ist kein Ersatz für das Shop-Framework Alice&Bob, sondern ein SaaS-Marktplatz.

    Ich hoffe damit ein paar Unklarheiten beantwortet zu haben.

    Fabian

Trackbacks

  1. Project A investiert 2015 gut 63 Mio. Dollar in Beteiligungen | 10 Jahre Exciting Commerce
  2. Exchanges #119: Kommt der Angriff der Großkonzerne? | 10 Jahre Exciting Commerce
  3. Siroop: Das “Happy Shopping” Projekt und die Pläne für 2016 | 10 Jahre Exciting Commerce

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: