Erfolgreich Vertikalisieren (Teil 2)

Erfolgreich Vertikalisieren (Teil 2) - im E-Commerce

Wir haben uns im 1. Teil dieser Reihe mit den grundsätzlichen Fragen von Vertikalisierung beschäftigt. Insbesondere, wo die Vertikalisierung Vorteile bietet, die über die technischen Muster der Self-Contained Systems (SCS) hinausgehen. In diesem Teil beschäftigen wir uns mit einer konkreten Vertikalisierung in der Domäne des E-Commerce. Hier hat neuland bereits einiges an Erfahrung sammeln können.

Zur Wiederholung: Die Grundvoraussetzung einer Vertikalisierung ist das Bedürfnis nach organisatorischer Skalierung. Wenn ein Unternehmen dauerhaft an einem System mit nicht mehr als einem Team arbeiten möchte, sind Systemschnitte in diesem System sehr kritisch zu bewerten. Die erste Regel verteilter Architekturen lautet, dass man sie besser vermeidet. Erst, wenn organisatorische Skalierungsbedürfnisse die Koordination der Arbeit zu vieler Menschen an einem zentralen System zu aufwändig machen, überwiegen die Vorteile einer Vertikalisierung.

Nutzer*innen-Motivationen im E-Commerce

In Teil 1 habe ich beschrieben, dass wir uns nach einem Schneiden nach bekannten Domänen nicht mehr an "klassischen" Organisationseinheiten für das weitere Schneiden orientieren können. Der nächste Schritt wäre, nach unterschiedlichen Nutzendengruppen Ausschau zu halten, deren Bedürfnisse/Probleme so verschieden sind, dass sich eine Systemtrennung anbietet. Wir befinden uns in unserem Beispiel in der Domäne des E-Commerce. Wer sind hier die Nutzenden?

Nutzende im E-Commerce-Umfeld

Ein E-Commerce-System wird für die zentrale Nutzenden-Gruppe der Kund*innen entwickelt. Üblicherweise wird so ein System aber auch von Mitarbeitenden genutzt: Zum einen, um Kund*innen zu assistieren/beraten, zum anderen, um die Inhalte zu erzeugen und zu pflegen, die benötigt werden, um die Bedürfnisse der Kund*innen bedienen zu können ("Content-Pflege").

Kund*innen

Die zentrale Nutzendengruppe, für die ein E-Commerce-System gebaut wird, sind die Kund*innen. Sie sollen im digitalen Self-Service ihre Bedürfnisse unter Zurückgreifen auf die Produkte/Dienstleistungen des Anbieters befriedigen können.

Customer-Support

Neben dem zentralen digitalen Self-Service für die Kund*innen gibt es üblicherweise auch noch einen "Customer-Support" (oder auch: "Kundenservice", "Customer-Care" o.ä.). Die Mitglieder dieser Nutzendengruppe bieten über Kanäle wie E-Mail, Telefon, Chat etc. den Kund*innen bei der Befriedigung ihres jeweiligen Bedürfnisses eine Assistenz/Beratung an. Diese Gruppe hat also als zentrales Aufgabenfeld auch die Bedürfnisse der Kund*innen zu bedienen. D.h.: Ein technisches System, was die Mitglieder eines "Customer-Support" unterstützt, muss im Wesentlichen die gleichen Ziele und Motivationen (d.h. Use-Cases) bedienen wie der Self-Service-Bereich eines Online-Shops: Die Bedürfnisse der Kund*innen.

Content-Kurator*innen

Die auf einer E-Commerce-Plattform angebotenen Produkte und Inhalte müssen hergestellt oder eingekauft werden. Die Produkte und ihre für Produktion und/oder Einkauf nötigen digitalen Repräsentationen werden in den uns bekannten Organisationskontexten von "vorgelagerten" Abteilungen und deren Systemen erzeugt/verwaltet: Unternehmensbereiche "Einkauf", "Produktion" u.ä.

Um diese Produkte dann in einer E-Commerce-Plattform zu verkaufen, müssen die aus der Produktion oder dem Einkauf vorliegenden digitalen Repräsentationen zu diesen Produkten so aufbereitet werden, dass man die Bedürfnisse der Kund*innen optimal bedienen kann. D.h., man muss den Kund*innen ermöglichen, passende Produkte zu finden, zu bewerten und zu erwerben.
Dazu müssen z.B. die Produkte eines Anbieters mit den notwendigen Produkt-Informationen versehen werden (Produktbilder, Texte, Maße, Farben, etc.).

Diese Erstellung/Anreicherung/Verbesserung von Content ist ein IT-gestützter Produktionsprozess, bei dem die Bedürfnisse der Kurator*innen nach effizienten Pflegeprozessen im Vordergrund stehen. Die benötigten Daten und ihre Qualität leiten sich zwar von den Kund*innenbedürfnissen ab, aber die Use-Cases zur Aufbereitung dieser Daten entstehen durch Effizienzbedürfnisse für die Arbeitsprozesse der Kurator*innen.

Fazit

Wir können für Kund*innen und Kurator*innen bereits eine fachliche Trennung anhand der grundsätzlich differierenden Bedürfnisse vornehmen: Die Kund*innen möchten anhand des Angebots der Plattform ein persönliches Problem außerhalb des anbietenden Unternehmens lösen. Z.B. eine Hose für die kommende Saison kaufen. Die Kurator*innen möchten ein Problem innerhalb des anbietenden Unternehmens effizient lösen. Das sind z.B. tägliche Änderungen einer Homepage, oder die Anreicherung von Informationen an Produkten etc.

Aufgrund der unterschiedlichen Nutzendengruppen/Bedürfnistypen bietet es sich bei einem Skalierungsbedürfnis an, für Kund*innen und Kurator*innen nicht die gleichen Systeme zu bauen, da ihre Bedürfnisse sehr verschieden sind.

Vertikalisieren anhand der Bedürfnisse der Kund*innen

Ein E-Commerce-System hat nun als zentrale Nutzendengruppe die Kund*innen und die Kund*innen-Assistenz eines "Customer-Supports". Die benötigte Entwicklungsleistung für neue Features und Anpassungen alter Features, um mit den Veränderungen am Markt mithalten zu können, ist inzwischen so hoch, dass das organisatorische Skalierbedürfnis bei immer mehr Unternehmen über die kritische Teamgröße eines einzelnen Teams hinausgeht. Bei den letzten Projekten, an denen neuland beteiligt war, sprechen wir von Dimensionen von 5-7 Teams mit bis zu ca. 50 Entwickelnden/POs, die dauerhaft Software entwickeln.

Wenn also ein Unternehmen z.B. mit 50 Personen an seinem E-Commerce-System entwickeln möchte, muss es für die effektive und effiziente Arbeit mehrere kleine Teams bilden und diese organisatorisch und technisch entkoppeln.

Die Idee der Vertikalisierung beruht darauf, die Motivationszustände bzw. Problemstellungen der Nutzer*innengruppe (also der Kund*innen) zu systematisieren, die diese auf dem Weg zu ihrer Bedürfnisbefriedigung durchlaufen (s. Teil 1 dieser Reihe).

Kund*innen-Motivationen beim E-Commerce

Bekannte Motivationszustände, die in unseren bisherigen Vertikalisierungen universell auftraten und mit denen wir bei bisher 5 Vertikalisierungen sehr gute Entkopplungsergebnisse erzielen konnten, sind die folgenden:

• "SUCHEN": Es gibt immer Kund*innen, die bereits eine konkretere Idee davon haben, was sie erwerben wollen. Dazu müssen sie herausfinden, was das beste Angebot ist. Nutzen sie dafür digitale Services, kennen sie entweder bereits einen Anbieter, von dem sie glauben, dass er sie bei der Suche sehr gut unterstützt (Artikel/Leistungen sind gut und sie sind dort leicht zu finden). Oder sie nutzen Meta-Anbieter wie Suchmaschinen, soziale Netzwerke etc. Zentral ist bei dieser Motivation, dass aus Kund*innensicht schnell viel verglichen ("gescannt") werden muss. Das ist ggfs. sehr zeitaufwändig. Daher sind Suchfunktionen, die schnell das Gesuchte zeigen, ein kritischer Wettbewerbsvorteil.
• "ENTDECKEN": Haben Kund*innen kein sehr konkretes Ziel oder konnten sie es nicht erreichen, befinden sie sich in einer weniger gerichteten Suchhaltung: z.B. weil sie gerade einen Artikel, den sie gesucht haben, in den Warenkorb gelegt haben, oder weil sie lange erfolglos gesucht haben, oder wenn sie mal auf der Homepage vorbeischauen bzw. einen Newsletter abonnieren, um sich überraschen zu lassen. Diese Motivation ist in der Regel nicht stark fokussiert. Wir nennen sie "ENTDECKEN", weil die Kund*innen dann nicht mehr stark selbst den Suchprozess steuern, sondern unfokussiert und bereit sind, sich beraten oder überraschen zu lassen.
• "BEWERTEN": Glaubt eine Person, etwas Relevantes gefunden zu haben, will sie das Gefundene noch mal in allen digital möglichen Aspekten betrachten können, um final zu entscheiden, ob sie es kaufen möchte. Es können auch mehrere Artikel für eine Art Vergleich vorbereitet worden sein. Im Idealfall kann die Person sehr schnell entscheiden, ob sie etwas gefunden hat, was ihrem Bedürfnis wahrscheinlich entspricht oder nicht. Im positiven Fall legt sie das Produkt in den Warenkorb oder eine Merkliste. Im negativen Fall wechselt die Person vielleicht in die "SUCHEN"- oder "ENTDECKEN"-Motivation zurück. Entweder, weil sie trotz Kaufvorbereitung noch weitere Dinge suchen/bewerten möchte, oder weil das Gefundene nicht ausreichend gut/sicher scheint und sie weitere Alternativen anschauen möchte.
• "KAUFEN": Will die Kund*in den Inhalt ihres Warenkorbs kaufen, möchte sie so einfach/schnell und sicher wie möglich den Kauf abschließen.
• "PRÜFEN": Ist der Kauf abgeschlossen, tritt die Kund*in ggfs. mit der Plattform noch mal in Kontakt, um den Fortschritt ihres Kaufs zu überprüfen: Wo bleibt die Sendung? Ist die Zahlung vermerkt oder steht sie noch aus? Ist der Gutschein korrekt verrechnet worden?
• "ZURÜCKGEBEN/RETOURNIEREN": Gibt es nach Erhalt Gründe, das Erworbene zurückzugeben (passt nicht, schadhaft, etc.), dann möchten Kund*innen das möglichst einfach tun können.

Je nach Markt eines Anbieters kann es bezogen auf das spezifische Produkt-/Service-Angebot auch weitere/andere Motivationen geben. Beispiele könnten sein "LERNEN" (DoItYourself), "UNTERHALTEN LASSEN" (Szeneklatsch), "PLANEN" (z.B. Küchenplaner), "HELFEN LASSEN" (z.B. Zusammenbau) usw.

Die Plattform nach Kund*innenmotivationen zerteilen

Genau anhand dieser Motivationszustände haben wir unsere Teams/Systeme schon in mehreren Plattformneubauten geschnitten. Die Wahrscheinlichkeit, dass Kund*innen nun an einer Stelle mit ihrer Motivation ein verbesserbares Erlebnis haben und die Verbesserung innerhalb eines Teams geleistet werden kann, ist sehr groß.
Alles, was im Rahmen der Motivation "SUCHEN" im User-Interface passiert, liegt dann in der Hand eines Teams.

Mittels des SCS-Musters und der Technik der Transklusion wird das User-Interface der Systeme zusammengesetzt. Denn die Interfaces unterstützen die gewünschten Motivationswechsel häufig zusammen auf einer Web-Page. D.h. während eine Kund*in einen Artikel "BEWERTET", bietet z.B. der Seiten-Kopf meistens Einstiege zurück in den Motivationszustand "SUCHE" (Navigation, Freitextsuche) oder einen Sprung zum Warenkorb, um zu "KAUFEN". Die zuständigen Teams steuern ihren Teil einer Seite per Transklusion bei.

Auf diese Weise können die Teams sich nur auf Lösungen des für sie relevanten Motivationszustands fokussieren und dort besser werden.

Der "Customer Support" wird den überwiegenden Teil seiner Use Cases nach dem gleichen Schnittmuster aufteilen können. Hier werden Produkte gesucht, die Kund*innen z.B. im Chat oder am Telefon beschreiben. Kaufprozesse, die Kund*innen nicht allein bewältigen, können mit Mitarbeitenden-Assistenz angeboten werden u.ä.

Erfahrungen

In bereits 5 Vertikalisierungen von E-Commerce-Plattformen hat neuland die Erfahrung gemacht, dass die geschilderten Schnittmuster zu großer Entkopplung im Bereich der Use-Cases für die Kundenmotivationstypen führen. Jedes Team deployt z.B. bis zu 20 mal am Tag seine Software und muss sich mit keinem anderen Team abstimmen, weil es End-To-End-Verantwortung hat. Die Teams bauen, warten, betreiben User-Interface, Geschäftslogik und Persistenzmechanismen. Und sie haben sehr wenige Abstimmungsthemen untereinander.

Insbesondere die Testabsicherung durch automatisierte Tests benötigt mit diesem Muster kaum integrative Tests, was trotz der hohen Deploymentfrequenz eine hohe Robustheit an den Schnittstellen zu anderen Teams ermöglicht.

Im folgenden schildere ich einige wertvolle Erfahrungen (ohne Anspruch auf Vollständigkeit).

Namen von Vertikalen

Wir haben in den Projekten beobachtet, dass diese Art des Schneidens kontraintuitiv für klassische Organisationen und in solchen Organisationen beheimatete Entwickelnde ist. Normalerweise sind Unternehmen gewohnt, ihre Organisationeinheiten nach Tätigkeiten im Unternehmen zu benennen und nicht nach Problemklassen der Umwelt. So lange die organisatorische und technische Architektur auf Tätigkeitsgruppierung basiert (Einkauf, Marketing, Logistik, Buchhaltung etc.), liegt nur ein Ordnungsmuster vor. Beginnt man aber, wegen des Änderungsdrucks crossfunktional in Teams zu arbeiten und sich statt nach Tätigkeiten im Unternehmen nach Problemklassen der Nutzenden (Kund*innen) zu organisieren, führt man ein zweites Organisationsarchitekturmuster ein. Diese beiden Organisationsmuster müssen nun koexistieren und verstanden werden (besonders in Grenzbereichen). Dabei ist es sehr wichtig, das neue Muster davor zu schützen, dass das "alteingesessene" Muster es wieder "assimiliert", sonst gehen die Vorteile verloren. Hier sind genaue Sprache und besonders Benennungen wichtig. Ein Team sollte z.B. besser "ENTSCHEIDEN" genannt werden, statt es z.B. "DETAILSEITE" zu nennen, damit die Entkopplungen der Usecases im Problemraum "Entscheiden" erhalten bleiben, so dass bei neuen Features/Änderungen die Frage des Problems der Nutzenden als Ordnungskriterium bestehen bleibt und nicht, welche Seiten man (im Moment) anzeigt, um die bisher angegangenen Kund*innenprobleme zu lösen.

Wenn die Hypothese stimmt, dass das Vertikalen-Schnittverfahren besser entkoppelt als die bisher üblichen, dann ist es effizienter (günstiger) und effektiver (Kund*innen zufriedener). Und damit ist es die kognitive Reibung wert, die diejenigen erleiden, die mit beiden Organisationsmustern zu tun haben: Dem "klassischen" Ansatz der Strukturierung nach Tätigkeiten und der vertikal dazu laufenden Strukturierung nach Kund*innenbedürfnissen.

Vertikalisierung und DDD

Der überwiegende Teil aller Entwickelnden ist es gewohnt, seine Systeme intern nach Objekten mit Daten und den Operationen darauf zu organisieren (OOP-Paradigma). Domain Driven Design (DDD) entwickelt sich langsam zum "next-level"-OOP und macht die technische Sprache rund um die OOP-Modellierung reichhaltiger. DDD beschäftigt sich auch intensiv mit der Schnittfrage auf der Ebene von Organisationseinheiten. Aber DDD ist agnostisch gegenüber der Frage, ob die aktuelle Organisationsstruktur gut geeignet ist oder nicht. DDD versucht, die Organisationsstruktur im Wesentlichen einfach widerzuspiegeln, damit man keine Schmerzen mit Conway's Law bekommt. In der funktionalen Modellierung stellen sich einige Fragen anders, aber auch hier gewinnt DDD an Bedeutung und sind die vorgefundenen Organisationsstrukturen wichtiger als die Suche nach einer neuen Arbeitsorganisation.

Das bedeutet, dass Vertikalisierung und DDD sich ergänzen müssen: Vertikalisierung beschreibt eine effizientere und effektivere skalierte Organisationsform für besonders dynamische Bereiche. DDD dient dazu, die technische Seite dieser neuen Organisation nachhaltig zu bauen.

Plattform-Engineering

Je nach Randbedingungen kann es noch notwendig sein, für Infrastruktur-Aufgaben ein Plattform-Team zu unterhalten. In heutigen Cloud-Umgebungen ist es dagegen möglich, auf solch ein Team zu verzichten, da ein Großteil vom Cloud-Anbieter automatisiert erbracht wird. Die Qualität heutiger PaaS- und SaaS-Lösungen ermöglicht inzwischen, mit vertretbarem Aufwand eine Plattform dezentral mit Teams zu betreiben, deren Hauptaufgabe die Entwicklung von Features für ihre Kund*innengruppe ist. Die noch verbleibenden Aufgaben im Bereich der Infrastuktur lassen sich auf die Teams verteilen, wenn die Teams passend besetzt sind: Es muss in jedem Team ausreichend Ops-Expertise bzw. -Begeisterung geben, damit die Ops-Aufgaben in ausreichender Qualität autonom gelöst werden können.

Beim letzten Vertikalisierungs-Kunden konnte unser Kunde mit neuland-Unterstützung eine komplette Betriebsumgebung für eine E-Commerce-Plattform bei einem Cloud-Anbieter innerhalb von 4 Wochen in Betrieb nehmen. Seit über einem Jahr wird sie dezentral betrieben und kein Team möchte zurück zum alten Muster. Allerdings muss die Teambesetzung mit mind. einem/r Ops-Begeisterten sichergestellt werden, der/die das Thema Operations im Team den Bedürfnissen entsprechend verbreitern kann.

Software-Qualität

Die Vertikalisierung gibt das Versprechen hoher Effizienz durch starke Entkopplung. Aber die Effizienz innerhalb der Vertikalen bleibt nur erhalten, wenn die Teams über ausreichend Erfahrung in der Softwareentwicklung verfügen. Nur so gelingt es ihnen, dauerhaft wartbare Softwareprodukte zu entwickeln. D.h. die Teams müssen nicht nur grundsätzliche Kenntnisse vom Programmieren besitzen, sondern auch über Erfahrungen mit Test-Driven Development, Domain Driven Design, vollautomatisierten Deployments und agilen Werten und Methoden verfügen, um nachhaltige Software entwickeln zu können. Andernfalls ist der Software eines Teams kein langfristiger Erhalt der Qualität beschert.

Wenn Teams nicht mit ausreichend Erfahrung besetzt sind, müssen sie ergänzt werden, bzw. durch erfahrene Personen im Team eine entsprechende Aus-/Weiterbildung organisieren. In den Projekten haben wir in solchen Fällen z.B. intern Coding-Dojos und Lesekreise gestartet und externe Fortbildungen organisiert und durchgeführt. In seltenen Fällen mussten wir allerdings Teams auch verändern, weil sie trotz aller Maßnahmen nicht ausreichend arbeitsfähig wurden.

Marketing... und andere Unternehmensinteressen

Letzten Endes möchte ein Unternehmen Geld verdienen. Und auch wenn eine E-Commerce-Plattform sich dabei vor allem an den Kund*inneninteressen orientieren und danach schneiden lässt, gibt es Unternehmensinteressen, die keinem direkten Kund*inneninteresse entsprechen. Das offensichtlichste Unternehmensinteresse ist das wirtschaftliche Überleben. Dazu kann das Unternehmen z.B. versuchen, die Marge zu steigern, indem es Preise erhöht, so lange Kund*innen bereit sind, sie zu zahlen. Das widerspricht dem Kund*innenbedürfnis, den kleinsten Preis zu bekommen. Gleiches gilt für Marketingmaßnahmen zu Imageänderung oder Kund*innenneugewinnung. Diese nicht von Kund*inneninteressen abgeleiteten Use-Cases passen häufig nicht direkt zu den an Kund*innenbedürfnissen orientierten Schnitten. Z.B. lässt sich die Aufgabe, aggressiv Newsletter-Adressen zu gewinnen, zwar einem Team geben, damit die Verantwortung geklärt ist, aber gerade aggressive Newsletter-Layer lassen sich nicht direkt von einem Kund*innenbedürfnis ableiten, und damit entstehen für Vertikalen zusätzliche Ziele, die dem Kund*innen-Hauptziel sogar zuwiderlaufen können. Z.B. muss das BEWERTEN-Team abwägen, ob es Kund*innen auf einer Produktansicht einen "Newsletter-Layer" des Newsletter-verantwortlichen Teams zumutet, auf die Gefahr hin, dass die Kund*innen genervt den Besuch abbrechen.

Nachhaltigkeit

Für die selbstorganisierten Teams ist es eine Herausforderung, das Spannungsfeld um Kund*innenbedürfnisse und Unternehmensbedürfnisse auszuloten. Hinzu kommt noch die Nachhaltigkeit der Entwicklung. Wird der Druck für die Unternehmensbedürfnisse (Kosten sparen) zu groß, lassen Teams notgedrungen ihre Qualitätsansprüche sinken, da die Kosten dafür erst deutlich später und viel diffuser wirksam werden. Vertikalisierte Teams müssen kaum noch auf etwas warten. Sie haben kaum Abhängigkeiten zu anderen Teams, benötigen kaum koordinative Meetings mit anderen und können daher Druck nicht mit Bezugnahme auf "äußere Umstände" abwehren. Stattdessen können sie es nur aus eigener Kraft tun.

D.h. vertikalisierte Teams müssen dem direkten Kund*innennutzen durch die nächsten Features immer den langfristigen Nutzen nachhaltiger Software entgegenhalten können.

Diese Wehrhaftigkeit ist nicht leicht zu fördern und Bedarf viel Erfahrung und auch stetiger Unterstützung aus dem organisatorischen Umfeld. Bei Beteiligung von Dienstleistern kommt außerdem noch erschwerend hinzu, dass diese in die Arbeitsbeziehung auch noch ihre eigenen Bedürfnisse mit Endkund*innenbedürfnissen und Auftraggeber*innenbedürfnis in Einklang bringen müssen.

Teaminteressen

Langfristig stabile, eingespielte Produktteams profitieren stark von ihrer fachlichen Expertise und sind extrem performant. Um die Teams möglichst stabil zu halten, müssen daher Teambedürfnisse neben Kund*innen- und Unternehmensinteressen berücksichtigt werden. Bei zu viel Fluktuation sind Qualität und Nachhaltigkeit aufgrund des Verlusts an Expertise gefährdet. Dementsprechend müssen auch für die Teams ggfs. Kompromisse eingegangen werden: Auf den ersten Blick ist es sehr effizient, einheitliche, etablierte Werkzeuge für alle Teams festzulegen: Betriebsrisiken sind dadurch geringer, es muss weniger in Lernkurven investiert werden, Teammitglieder können sehr effektiv kurzfristig anderen Teams aushelfen etc.

In unseren Projekten hätten wir dann aber mehr Schwierigkeiten gehabt, Teams aufzubauen und langfristig stabil zu halten. Denn für viele Entwickelnde ist technologische Vielfalt und Modernisierung ein wichtiger Aspekt der Arbeitszufriedenheit und persönlichen Weiterentwicklung, auch wenn darunter Effizienz und Effektivität leiden, weil jede neue Technologie natürlich auch eine steile Lernkurve in der Anfangsphase erfordert, und weil mehr technische Komplexität die kognitive Last in der Gesamtplattform erhöht.

Gilden

Um Synergien zwischen den Teams nutzen zu können, ist es wichtig, Mechanismen zu installieren, die eine Kultur des Austauschs fördern. Das, was wir Gilden nennen, ist dabei ein probates Mittel. Damit meinen wir unterschiedlich lockere Gruppen, in denen sich gelegentlich interessierte Teammitglieder treffen, um sich zu helfen, Inspiration zu geben, aber auch um Arbeit zu sparen, weil man vielleicht voneinander kopieren oder untereinander teilen kann. Typische Gilden in unseren Projekten gab es zu den Themen:

• Makro-Architektur
• Frontend-Architektur
• Ops
• User-Experience-Research
• Data Science

Es gab aber auch Spezialformen, in denen es eine Pflichtteilnahme gab:

• Security. Hintergrund war, dass die Teams erst noch ausgebildet werden mussten.
• Compliance, ebenfalls Ausbildungsbedarf
• Kubernetes. Da wir beim damaligen Cloud-Anbieter keine attraktive SaaS-Lösung für den kubernetes-Cluster entdeckt haben und der Betriebsaufwand leistbar ist, haben wir bereits in zwei Projekten kubernetes selbst in der Cloud betrieben. Die kubernetes-Gilde stellt Betrieb, Wartung und Wissensverteilung sicher. Alle Teams steuern durch Mitarbeit dazu bei. Hier ist insbesondere die Betriebsverantwortung (Bereitschaft) eine spezielle Herausforderung, die die Gilde zu meistern hat.

Dieser Gildenbetrieb funktionierte bisher sehr gut und ist ein attraktives Muster für Selbstorganisation. Manche Gilden existierten nur temporär. In jedem Fall passten sie Häufigkeit und Dauer ihrer Zusammenkünfte über gelegentliche Retrospektiven an, bei denen sie regelmäßig die Arbeitsweise reflektierten.

Wie schneidet man weiter?

Angenommen, die Geschwindigkeit der Weiterentwicklung und des Testens innovativer Ideen reicht noch immer nicht: Statt 6 Teams möchte man 20 parallel arbeiten lassen. In diesem Fall ist mit dem jetzigen Muster eine weitere Unterteilung mit Vertikalen für die Behandlung von Kund*innenmotivationen möglich: Z.B. kann ein "SUCHEN"-System weiter zerlegt werden in verschiedene Produkte: "Suche per Navigation", "Suche per Freitexteingabe", "visuelle Suche" etc. Ein "BEWERTEN"-System kann in ein System für die Bewertung von Outfits, eines für Schmuck o.ä. zerlegt werden.

Doch je kleinteiliger die Schnitte werden, desto wahrscheinlicher wird ein Koordinationsbedarf. Die genannten 3 Beispieltypen für Suchformen der Kund*innen konkurrieren miteinander um den Zugang der Kund*innen. Alle drei wollen ihren Zugang zum Suchproblem ja immer besser machen. Wer entscheidet nun, wann welche Suchform für die Kund*in wie prominent erkennbar wird? Wie kann man an so einem Punkt lokalen Optima entrinnen? Weder wissen wir schon, ob das wirklich relevante Fragen sind, noch kennen wir die Antworten. Denn so weit mussten wir noch nicht skalieren.

Stärkere Kopplung

Ab einem bestimmten Punkt wird ein weiteres Schneiden nur noch möglich, indem man synchrone Schnittstellen zulässt, weil Invarianten-Grenzen unterschritten werden. Eine Unterteilung von "KAUFEN" in "Registrieren", "Liefern" und "Bezahlen" wäre aus Sicht des fachlichen Schnitts erst einmal passend, da es aus Kund*innensicht gut voneinander trennbare Herausforderungen sind. Leider gibt es zwischen diesen drei Bereichen aber eine fachliche Kopplung, die (im Sinne der Konsistenzanforderung) synchrone Schnittstellen erforderlich macht. Jede Änderung während eines Bestellprozesses in einem der drei Systeme kann auf Geschäftslogik in einem anderen Einfluss haben. Eventual Consistency ist in der Regel in einem Bestellprozess keine Option, weil man dort bei Inkonsistenzen schnell das Vertrauen der Kund*innen verliert.

Um keinen inkonsistenen Zustand erzeugen zu können, müssen die Systeme bei Änderungen synchron die anderen informieren. Wird z.B. von "Bezahlen" die Zahlungsart auf Nachnahme geändert, kann "Liefern" keine Lieferung mehr an eine Packstation erlauben. Ändert sich bei "Registrieren" die Rechnungsadresse, verändert das evtl. das Bonitätsscoring und dadurch ändert sich die Gültigkeit von Zahlungsarten. Und weil alle Bereiche für eine gültige Bestellung einen validen Zustand benötigen, braucht man auch noch eine Koordinationsinstanz, die entscheidet, dass eine Bestellung vollständig und korrekt ist.
Ist dieser Punkt erreicht, verlässt man die einfache Welt der fachlich starken Entkopplung und gleichberechtigten Systeme und erhält synchrone Schnittstellen, wie man sie häufig bei naiven Microservice-Architekturen findet. Und manchmal lassen sich sogar Service-Hierarchien nicht vermeiden, bei denen die eine Service-Ebene Geschäftslogik für andere Ebenen anbietet. Um aber die Kopplung unter diesen Services so gering wie möglich zu halten, gelten weiterhin die Gesetze einer Vertikalisierung:

• Nach Kund*innenproblemen schneiden, um sich bei der Produktentwicklung möglichst selten mit anderen Teams abstimmen zu müssen.
• möglichst Self-Contained Systems als Konstruktionsmuster verwenden mit der Einschränkung, dass synchrone Schnittstellen unvermeidbar werden.

Projektmanagement trifft auf Produktmanagement

In den bisherigen Vertikalisierungen wurde das Problem deutlich, dass eine auf die IT beschränkte Vertikalisierung viele Potentiale bei Effektivität und Effizienz liegenlässt: Andere Bereiche im Unternehmen überlegen sich Projekte ("Business Development", "Logistik", "Finance" usw.), ohne selbst vertikalisiert aus Kund*innensicht zu planen. Bis solche Projekte auf die vertikalisierte Plattform treffen, haben sie häufig große Dimensionen. Dadurch leidet die Effektivität, weil ineffektive Features nicht durch MVP-Tests aussortiert werden können. Außerdem führen Großprojekte zu vertikalenübergreifenden Planungsmustern, die die Effizienz mindern, weil es mehr Koordinationsbedarf gibt, mit all den bekannten Verlusten.

Fazit

Eine E-Commerce-Plattform-Entwicklung kann durch Vertikalisierung mit dem genannten Schnittmuster organisatorisch sehr effizient skaliert werden. Viele Potentiale für mehr Effektivität (das Richtige tun) und Effizienz (Dinge mit minimalem Aufwand tun) können aber nicht genutzt werden, wenn die Vertikalisierung auf die IT beschränkt bleibt. Um dagegen etwas zu tun, sind viel weitreichendere Überlegungen notwendig. Doch dazu in Teil 3...