Eine Frage, die wir uns schon lange gestellt haben, war:  was wollen wir mit unserem Webshop machen? Dieser ist mittlerweile etwas in die Jahre gekommen. Wir sind zum Entschluss gekommen, er passt nicht mehr, und wir wollen ihn ablösen.

Fragen wie

• Wie leicht können Änderungen durchgeführt werden?
• Wie gut passt er zu unserem fachlichen Zielbild?
• Wie gut passt er zu unserer Organisation (Conway’s Law)?

sind  für uns wichtige Kriterien und haben zu dieser Entscheidung geführt.

Nur durch was wollen wir unseren Webshop ersetzen?

Wenn wir etwas ablösen wollen, müssen wir auch sagen, wodurch wir das ablösen wollen.  Die erste Frage ist: wie groß ist eigentlich das „Greenfield“?

Neben den gewünschten Funktionalitäten  gibt es noch eine Reihe weiterer Kriterien zu beachten:

• Wie gut integriert es sich in unsere bestehende IT Landschaft?
  Wir wollen nicht unsere komplette IT Landschaft (ERP, Suche, CRM, Analytics,…) umstellen. Nach dem „best of breed“-Ansatz sind da zum Teil Kauflösungen unterschiedlicher Hersteller zum Teil Eigenentwicklungen dabei.
• Wie integriert es sich mit der bestehenden Organisation & Prozesse?
  Mit z.B. .NET kennt sich hier kaum jemand aus ;-)), wir haben cross-funktionale Produktteams, die das realisieren sollen.
• Wie weit passt es zu unserem geplanten Projektverlauf?
  Wir wollen iterativ vorgehen und parallel weitere Projekte realisieren.

Auswahl des Shopsystems

Es gibt ziemlich viele eCommerce Systeme – Open Source, On Premise, SaaS Lösungen etc. Trotzdem haben wir uns gegen eine Standardlösung entschieden und realisieren hauptsächlich mit einer Individuallösung. Wir wollen Systeme haben die sich uns anpassen und nicht unsere Organisation, Prozesse, fachliche Features an Systeme anpassen.  Ein Standardsystem zu nehmen und so extrem anzupassen, dass es unseren Wünschen entspricht, halten wir für keine gute Idee.

Zielarchitektur definieren

Welche Architektur ist für uns die richtige? Wir sind von der Organisation und Komplexität so groß, dass wir uns in mehrere Teams aufteilen müssen.  Daher müssen wir in der Makroarchitektur einen Domänenschnitt finden, der den besten Trade Off zwischen möglichst kleinen Einheiten, möglichst wenigen Schnittstellen, möglichst hoher Kohäsion, möglichst hoher Änderbarkeit, möglichst stabilem Schnitt, möglichst geringer Kosten und noch vieles mehr bildet.

Domänenschnitt

Wir haben uns dafür entschieden,  dass eine Kundenfunktionalität möglichst komplett von einem einzigen Team betreut wird. D.h., ein Team ist z.B. für die Artikelsuche zuständig – und das idealerweise von der Visualisierung zum Kunden über die eigentliche Suche bis zur Datenversorgung der Suchmaschine.  So sind unsere Produktteams geschnitten und so sollen sie sich auch in unserer technischen Abbildung widerspiegeln.
Da wir nicht nur eine Webseite haben sondern auch Native Apps und spezielle eReader Anwendungen, sind unsere Frontend Technologien sehr vielfältig.

Daher haben wir uns zu einem Kompromiss entschieden. Für Webseiten geht die Teamverantwortung bis in die Visualisierung. Für Native Anwendungen greifen unsere Frontend Spezialisten auf Service APIs zu.  Er ist also ein Funktionaler Schnitt für Webseiten und eine Schichtenarchitektur für Native Frontends.
Wir orientieren uns für die Webseiten an der SCS Architektur, allerdings haben wir viele Service APIs und stellen zum Teil beide APIs zur Verfügung – eine HTML Webseite und eine native Suche, die dann im Hintergrund eine Rest-API verwendet. Wir haben uns dafür entschlossen, da Webseiten unser Hauptfokus sind und wir nicht immer einer Service API brauchen. Wie immer gibt es Vor- und Nachteile, aber diese Lösung fühlt sich gut an und hilft uns, unsere Omnichannel Plattform aufzubauen.

Innerhalb der Teamgrenzen ist es jedem Team freigestellt, wie sie ihre Domäne aufteilen.  In der Praxis zeigt sich, dass diese in mehreren Microservices aufgeteilt wird – zum Teil auch hier ein Funktionaler Schnitt zum Teil nach Schichten. Wie das in der Praxis aussieht, kann man z.B. bei Team Kaufen sehen.

Kommunikation zwischen den SCS Systemen

Für die Kommunikation zwischen den SCS Systemen setzen wir bei synchroner Kommunikation auf REST Schnittstellen und bei asynchroner Kommunikation auf Events. Die Events werden über ein Messaging System verarbeitet und verteilt. Wir wollen möglichst asynchron kommunizieren.  Wir klären gerade, wie wir allen Systemen diese Technologien beibringen. Zum Teil müssen wir noch Lösungen finden, da nicht alle bestehende Standardsysteme solche Schnittstellen anbieten.

Zusammenfassung

Wir wollen einen Webshop haben, welcher  zu unserer neuen Organisation passt und sich leicht verändern lässt. Da unser jetziger Webshop dies nicht ausreichend leistet, wollen wir in ablösen.
Eine Standardlösung passt nicht, daher haben wir uns entschlossen, eine Individuallösung zu realisieren, die im Kern auf eine SCS Architektur aufsetzt. Für die nativen Frontends werden Service APIs verwendet.

Manuel Gomes Nunes

Senior IT Architect