Das Spryker-E-Commerce-Framework aus dem Stall von Project A Ventures hat sich diese Woche erstmals der Öffentlichkeit präsentiert und die ersten Reviews (“Spryker – eine erste Einschätzung”) haben vor allem bei Facebook für eine lebhafte Debatte gesorgt.
Spryker und andere Newcomer treffen in der Branche einen Nerv, weil sie die überfällige Trennung von Front- und Backend propagieren, wie wir sie in den Exchanges #52 (“Shopsysteme gestern, heute und morgen”) thematisiert haben, und sich zudem der leidigen Caching-Frage (“ShopTechTalks #5: Wie Globetrotter ohne Caching auskommt”) annehmen.
Mehr in der Shoptech-Rubrik und im Shoptechblog (“Spryker – Ein Blick hinter die Kulissen”).
Eine weitere Spryker-Präsentation ist für den 9.12. in Hamburg geplant.
Frühere Beiträge zum Thema:
- Die Shoptech-Ambitionen von Spryker, Ongr, Amplience und Wombat
- ShopTechTalks #6: About You und der Kundenmehrwert
- ShopTechTalks #5: Wie Globetrotter ohne Caching auskommt
- Exchanges #52: Shopsysteme gestern, heute und morgen
Kategorien:Shoptech
Danke für die Erwähnung! Spryker Session am Dienstag in Hamburg experimentieren wir auch mit einem Webstreaming Angebot. Anmeldungen bitte direkt an info@spryker.com In Hamburg haben wir aber nach aktuellem Stand noch 7 Plätze frei. Da freuen wir uns auch über interessierte Teilnehmer, die uns Löcher in den Bauch fragen.
Irgendwie erscheint mir das ganze nicht sonderlich schlüssig.
Auf der einen Seite soll das Framework für den Enterprise Bereich sein. Schön und gut – nur blöd, dass Innovationen oder neue Konzepte eben nicht aus diesem Segment kommen. Sie kommen von den kleinen Startups die im besten Fall – wenn überhaupt – ein paar 100k Euro als Venture Capital haben. (Wir sind leider nicht in den USA)
Und wenn es für den Enterprise Bereich gedacht ist – aber keine Features hat die eben dann manuell erstmal entwickelt werden müssen – ist es doch auch nicht rentabel. Wer, mit einem echten nachhaltigen Geschäftsmodell und Gewinn-Absichten – entwickelt erstmal 1-2 Jahre ein Framework so lange weiter, dass er am Ende zumindest mal die Standard-Features hat?
So sehr einige Berliner-Hipster das auch nicht wahrhaben wollen aber am Ende des Tages kommen die meisten großen Shops & Händler eben nicht ohne die “ungenutzten” Standard-Features aus. Die Kunden erwarten mindestens die gleichen Features wie sie auch ein Amazon hat.
Bei allem Respekt und ohne persönlich jemand angreifen zu wollen aber das Ganze ist doch hier eher ein Versuch aus einer technologischen Basis die mit extrem viel VC finanziert wurde nun noch ein paar Euronen zu machen – mit dem schallenden Namen von Zalando als große Referenz.
Ro
Wir betrachten den Trade Off zwischen Weiterentwicklungsgeschwindigkeit vs. Featuresetlänge. Auch in Spryker sind viele Standards bereits angelegt und vorgedacht, aber man kann sie nicht im Sinne konfigurierbarer Features ausrollen. Es gibt nirgends einen Button zur Einstellung der Mehrwertsteuer usw. Mit dem aktuellen Stand kommt man ja auch in wenigen Wochen zu einem ordentlichen E-Commerce System, dann aber stark individualisiert und ohne die Restriktionen aus monolithischen Systemen. Das ist nicht für jeden Anwendungsfall sinnvoll, das stimmt, aber es geht auch nicht zwingend um Innovationen für Startups.
ich finde den Begriff Enterprise irreführend.
Was der Markt definitiv braucht, sind “flexible(re)” Systeme/Frameworks für ambitionierte (sprich: schnell wachsende) Unternehmen und Unternehmen, die auf alternative Konzepte setzen, sich aber am Beginn noch nicht festlegen können (oder wollen), wie die finale Lösung aussieht – gemäß der alten Frage: Bestimmt das (Shop-)System das Geschäftsmodell (wie bei den gängigen Lösungen) oder das Geschäftsmodell die Systemlösung …
Ich denke, für wen Spryker gut ist, wird sich schnell zeigen, wenn ein paar Projekte damit gemacht wurden. Dann wird man Erfahrungen haben, wie aufwendig es für einen “angelernten” Partner ist, eine Spryker-Lösung zu bauen und wie sich das gegenüber Oxid oder Magento oder Hybris und Co. darstellt.
Framework, modularer Aufbau, gute Schnittstellen zwischen den Komponenten, das ist definitiv der Trend bei Web-Apps. Wenn man die Flexibilität behalten kann, ohne Entwicklungsgeschwindigkeit zu verlieren, bekommt man die SEINE IDEALE Individual-App.