Ein Kanal ist nicht genug. Weil der Trend zum Multi- bzw. Cross-Channel geht und die mobile Nutzung bei Kunden eine immer größere Rolle spielt, ist es nur folgerichtig, sich mit den technischen Herausforderungen zu beschäftigen - unter Beachtung der Ansprüche stationärer und Online-Händler. Michael Köster, CIO Advisory, KPMG AG und stellvertretender Vorsitzender der AG E-Commerce des BITKOM, beschäftigt sich in seinem Beitrag mit genau diesen Herausforderungen der IT-Architektur und zeigt prototypische Lösungsansätze auf, um mehr Flexibilität und weniger Komplexität bei der Umsetzung der Cross-Channel-Strategie zu erreichen.  

Michael Köster
Michael Köster

Stimmen die Voraussetzungen, liegt der Wunsch von Filialisten nahe, durch den Aufbau eines E-Commerce-Angebots, unter Berücksichtigung der neuesten Mobile-Commerce-Technologien, mit Einbindung einer breiten Palette von Payment-Verfahren und leistungsfähiger Social-Media-Konnektoren, vom Einkanalanbieter zum Multi-Channel-Retailer aufzusteigen.

Technisch betrachtet ist nichts davon wirklich Rocket Science, die prinzipielle Machbarkeit jedes einzelnen Elements ist für sich genommen gegeben. Das Problem ist die Beherrschbarkeit der technischen Komplexität und die kosteneffiziente Umsetzung des Vorhabens insgesamt – gerade in gewachsenen Strukturen und insbesondere wenn diese bereits unter »technischen Schulden« leiden. Der Gesamtaufwand der Umsetzung wird allzu schnell unterschätzt und vermeintliche Einsparungen bei der Planung und Pflege der Software-Architektur gehen schließlich gravierend zu Lasten der total cost of ownership.

Eine wohlüberlegte, konsequent angewandte Architekturstrategie ist die notwendige Voraussetzung für die Vermeidung dieser Kostenfalle. Neben der Umsetzung der funktionalen Anforderungen an ein IT-System, lässt sich mit Hilfe einer durchdachten Systemarchitektur die nachhaltige Unterstützung auch von nicht-funktionalen Anforderungen (NFR, engl. non-functional requirements) realisieren. Beispielsweise hängt die Wartbarkeit des Systems entscheidend von Umfang und Tragweite möglicher Seiteneffekte ab und somit von seinem architektonisch bedingten Zuschnitt (Single-Responsibility-Principle).

Problemstellung

Die besondere Herausforderung bei der Realisierung von Multi- und Cross-Channel-Architekturen liegt in der technischen Heterogenität der beteiligten Systeme. Je nach Anwendungsfall sind Mischungen von Thin-Clients im Browser (klassisches E-Commerce) mit Rich-Clients in den Filialen, im Support und in den Call-Centern keine Seltenheit. Die technologischen Herausforderungen an Online-Systeme sind durch Mobile Commerce und das Internet der Dinge infolge der größeren kombinatorischen Vielfalt aus Plattform, Betriebssystem und Browser-Engine sprunghaft gewachsen.

Durch die Integration der stationären Systeme in einen Cross-Channel-Ansatz prallt diese nun zusammen mit einer Welt, in der ein Release-Zyklus – etwa eines Kassensystems – leicht fünf Jahre betragen kann. Brick & Mortar-Stores verfügen ggf. nicht über Fernwartungssysteme und es gilt Wartungsverträge mit Drittanbietern mit jeweils eigenen Service-Level-Agreements zu berücksichtigen. Ein eigenes Customizing ist dem Retailer unter Umständen gar nicht erlaubt oder er muss dazu auf den Hersteller oder Third-Party-Anbieter vertrauen. Die Breite eines Cross-Channel-Commerce- Ansatzes bedingt, dass das Vorhandensein unterschiedlicher Technologie-Stacks akzeptiert und behandelt werden muss. 

Unabhängig vom Systematisierungsrahmen der funktionalen und nicht-funktionalen Anforderungen an das System – sei es das Volere-System, der ISO/IEC 9126-Standard oder das einfache FURPS-Modell – steht Software- Architektur im Spannungsfeld einander widerstreitender Anforderungen. Beispielsweise müssen in Multi-Channel- Architekturen die Übertragbarkeit (Ausführbarkeit in verschiedenen Umgebungen) und Änderbarkeit von Software-Logik im besonderen Maße gewährleistet sein, aber eben ohne Ziele wie Benutzbarkeit, Effizienz und Zuverlässigkeit zu beeinträchtigen. 

Lösungsansätze

Die zwei wichtigsten Ziele jeder Software-Architektur – Erhöhung der Flexibilität und Verringerung der Komplexität – sind grundsätzlich konträr. Zwar kann der Einsatz von Frameworks und Bibliotheken beiden Absichten zugleich dienen, der richtige Grad von Komplexität und Flexibilität muss aber dennoch pro System abgewogen werden. Gerade für Multi-Channel-Systeme bietet sich als grundlegende Strategie der Unternehmensarchitektur (Enterprise-Architecture) daher der Einsatz von Multi-Tier-Architekturen an. Unter Multi-Tier-Architekturen sind dabei keine Applikationsschichten à la: GUI Layer – Application Layer – Domain Layer – Infrastructure Layer zu verstehen, sondern vielmehr Systemschichten im Sinne eines (IT-) Bebauungsplans. Im einfachsten Fall besteht die Multi-Tier-Architecture aus zwei Schichten, die ausschließlich über eine fest definierte Schnittstelle – einen Abstraction-Layer – kommunizieren. Der Abstraction-Layer kapselt die Services der jeweils unteren Schicht, so dass sämtliche Aufrufe kontrolliert weitergegeben werden.

Multi-Tier-Architektur für Multi-Channel-Systeme
Multi-Tier-Architektur für Multi-Channel-Systeme


Im Fall von Cross- und Multi-Channel-Systemen für den E-Commerce-Einsatz besteht die oberste Schicht damit eben nicht nur aus einer Präsentationsschicht (GUI), sondern umfasst beispielsweise den gesamten Web-Shop, inklusive der zugehörigen Präsentationslogik, Geschäftslogik und Persistenzlogik. Die Webanwendung verwaltet ihre eigenen Kundendaten und synchronisiert diese nachfolgend über den Abstraction-Layer mit dem Backend. Die Frequenz der Abgleiche und die Frage nach synchroner oder asynchroner Kommunikation hängen von Art und Menge der Daten ab und sind Teil der Architekturentscheidungen. Durch die Integration von mindestens zwei unterschiedlichen Marketingkanälen (etwa mobile web und native app) entstehen echte Multi-Tier-Architekturen mit mehr als nur zwei Schichten. Regelmäßig werden die stationären Filialsysteme zentral in einem separaten Backend zusammengeführt und alle Online-Kanäle (web, mobile, ggf. Call-Center) zu einem anderen.

Der Ansatz birgt zwei entscheidende Vorteile. Erstens erlauben iterative asynchrone Synchronisationsprozesse eine effizientere Integration gewachsener Strukturen in ein System. Die bestehende Landschaft wird gekapselt und nach unten kontrolliert über die Abstraktionsschicht geöffnet. Zweitens können mit diesem Ansatz auch rechtliche Rahmenbedingungen, wie juristische Entitäten im Konzernverbund, ausreichend berücksichtigt werden. Exemplarisch seien Kundendaten genannt, die beileibe nicht zwangsläufig automatisch zwischen Töchtergesellschaften und Vertragspartnern (Franchise-Nehmer, unabhängige Händler) ausgetauscht werden dürfen. Den Vorteilen stehen aber auch Nachteile gegenüber.

So führt der »Separation of Concerns«-Ansatz zu erhöhten Entwicklungsaufwänden aufgrund der auch organisatorisch getrennten Projekte. Und es entstehen erhöhte Aufwände für den Technologie-Einsatz, also Hardware, Server, Betrieb und Lizenzen. Dies gilt umso mehr, als dass im Mehrschichtenmodell eine extrem zügige Kommunikation zwischen den Kanälen zwingend gewährleistet werden muss. Zusätzlich zu den inhärenten Latenzzeiten für die Übertragung der Daten dürfen für die Zusammenstellung von Inhalten im Back-End nur Bruchteile von Sekunden vergehen.

Auf den unteren Schichten einer Multi-Tier-Architektur kann eine niedrige Flexibilität und eine vergleichsweise schwerfällige Anpassbarkeit an kurzfristige Anforderungen in Kauf genommen werden, wenn dadurch ein sehr stabiler, wenig komplexer und sehr effizienter Architektur-Stack entsteht. Änderungen an den unteren Schichten sollten mit Bedacht, zielgerichtet und erst nach intensiver Abstimmung mit den Verantwortlichen der aufsetzenden Architekturschichten vorgenommen werden. Auf den oberen Schichten steht dagegen die schnelle Anpassbarkeit an neue Anforderungen im Vordergrund. Diese Schichten konsumieren in erster Linie, so dass ein System-Ausfall oder System-Versagen auf den jeweiligen Endpunkt beschränkt bleibt. Somit ist eine schnelle Adaption einer mobilen Webseite an neue Plattformen, Betriebssysteme und Browsergenerationen möglich, ohne grundlegende Business-Funktionen oder benachbarte Kanäle zu gefährden. Müssen schnelle Änderungen umgesetzt werden und wird dies temporär in den höheren Schichten gemacht, entspricht dieses Vorgehen der (legitimen) Aufnahme von »technischen Schulden«. Um den berüchtigten architektonischen »big ball of mud« mittelfristig zu vermeiden, ist es aber erforderlich die einmal gemachten Schulden schnell und beharrlichen mit den kommenden Releases der unteren Schichten und der Schnittstellen im Abstraction-Layer abzubauen. 

Eine wichtige Voraussetzung für die erfolgreiche Umsetzung des Multi-Channel-Schichtenmodells ist eine möglichst hohe Kohäsion der Schichten. Angesichts der großen Heterogenität ist nur die lose Kopplung der Elemente mit Hilfe plattformunabhängiger Standards langfristig beherrschbar. Durch die Verbreitung und Etablierung Service-Orientierter Architekturen werden offene Austauschformate wie XML oder JSON in der Zwischenzeit jedoch auch technologieübergreifend unterstützt. Eine hohe Kohäsion der einzelnen Elemente ist eine zwingende Voraussetzung, um den ohnehin erhöhten Kommunikationsaufwand untereinander nicht ausufern zu lassen. Die konsequente Berücksichtigung des Hollywood-Prinzips – »don’t call us, we call you« – von der GUI bis zum Backend reduziert Aufwände im Test und der Wartung der Anwendung erheblich. Die unidirektionale Kommunikation der Schichten garantiert auch die Vermeidung von zirkulären Abhängigkeiten.

Bei der Umsetzung von Cross-Channel-Strategien steht dieses Prinzip allerdings unter besonderem Druck. Die direkte Vernetzung etwa des in der Filiale installierten Equipments mit dem Smartphone des Kunden mag zunächst verlockend klingen. Sie ist auch gewünscht und zielführend, aber eben nur zur Definition eines ersten Kontaktpunkts. Wird eine Bluetooth-Konnektivität vom Handy zur Filiale genutzt, um die originäre Kommunikation der Smartphone-App mit dem Backend zu ersetzen, bedroht der Ausfall eines Teilsystems die gesamte Landschaft. Gibt die Bluetooth-Verbindung kassenseitig lediglich das Autorisierungssignal, so kann Übertragung beidseitig und transaktionssicher im Backend nachgehalten werden. Dies ist schon im Sinne regulatorischer Anforderungen, wie der Einhaltung der Grundsätze ordnungsmäßiger Buchhaltung, empfehlenswert.

Die technologische Breite von Multi-Channel- und Cross- Channel-Ansätzen bedingt auch praktisch zwangsläufig die verteilte Entwicklung von Software-Projekten. Das ist im Hinblick auf »Separation of Concerns« auch wünschenswert. Grundlegend ist aber die Schaffung und Fortführung eines einheitlichen Architektur-Verständnisses über alle Unternehmensteile hinweg. Architektur-Guidelines, Architektur-Standards und eine ausgeprägte Architektur-Modellierung sind notwendige flankierende Maßnahmen. Die Wahl der Modellierungssprache, sei es die Unified Modeling Language (UML), Domain Specific Languages (DSL) oder Architecture-Description-Languages sollte dabei nicht im Vordergrund stehen.

Wichtig ist, den Aufwand für die Dokumentation im Vorfeld und während der Fortentwicklung tatsächlich zu budgetieren und wirklich zu investieren; es wird sich im Hinblick auf die Gesamtkostenrechnung rentieren. Aber: don’t repeat yourself (DRY) is calling! Damit die einzelnen Kanal-Backends so wenig wie möglich redundante Funktion bauen, ist der Einsatz von und die ständige Überwachung durch ein Architektur-Board empfehlenswert.

Fazit 

Es ist offensichtlich, dass die Serienreife von Cross-Channel-Commerce einen erhöhten Aufwand gegenüber der Erstellung von unvernetzten Multi-Channel-Systemen erzeugt. Betriebswirtschaftlich sollten damit die total cost of ownership des gesamten Geschäftsmodells im Mittelpunkt stehen. Die Investitionen für einen Schnellschuss, nur um mit einer schnellen App auch irgendwie am mobilen Markt dabei zu sein, erweisen sich später leicht als unwiederbringliche Sunk Costs. Andererseits liegt der Vorteil des digitalen Produkts Software ja gerade in der auch nachträglich möglichen Änderbarkeit und der Option zur Weiterentwicklung. Durch die beharrliche Pflege einer a priori festgelegten, konsequent und konsistent berücksichtigten Architektur-Strategie kann den »schnellen Schuss« in eine breite Salve wandeln.

Software-Architektur sollte sich immer an den konkreten Anforderungen und Gegebenheiten orientieren. Der beschriebene Ansatz kann daher nur einen sehr groben Überblick geben. Er stellt ein prototypisches Ideal dar, welches als ein zwar nie erreichtes, aber stets gegenwärtiges Leitmotiv dienen kann.

Dieser Beitrag erschien zuerst im aktuellen Bitkom-Leitfaden „Cross-Channel-Commerce - Strategien und Technologien für erfolgreiche Digitalisierung im Handel“ (PDF).