Neulich beim Architekturreview

Neulich hatte ich einen Auftrag um den neuen Webshop eines Retailers zu bewerten. Ich bekomme ab und zu solche Anfragen zur Analyse, um den auftraggebenden Unternehmen Sicherheit zu geben und Handlungsoptionen zu eröffnen. Da ich die meisten bedeutenden Schweizer E-Commerce Systeme gesehen habe, und darüber hinaus jahrelang Entwicklungsteams führen durfte, dauert solch eine Analyse meistens nicht lange. Sie fördert neutral und kompetent etwaige Schwachstellen und Risiken zu Tage.

Ich habe es häufig erlebt, dass sich die Gespräche und Interviews im Rahmen eines Reviews sehr positiv auf die Zusammenarbeit zwischen Dienstleister und Kunde auswirken, weil beide Seite zum Zuge kommen und schwelende Konflikte zu Tage gefördert und aufgelöst werden können. Meistens möchte der Auftraggeber den Review auch nicht von ungefähr durchführen, sondern es gibt einen triftigen Grund. Insofern ist solch ein Architekturreview immer auch eine Moderation zwischen den Parteien. Neben der technologischen Expertise ist also ein gutes Gespür für die beteiligten Menschen nötig, um weiter zu kommen.

Das fragliche System war lange in der Entwicklung bei einem Dienstleister, und seine Einführung mit mehr als einem Jahr Verzug überfällig. Die Geschäftsleitung, die den Review bei mir in Auftrag gab, sorgte sich darum, ob das System überhaupt fertig werden würde, und wie es um die Zukunftsfähigkeit der Lösung bestellt sei. Bei der Analyse war ich dann überrascht, wie wenig Unternehmensarchitektur heute immer noch betrieben wird, und welche Konsequenzen dies für ein Geschäft haben kann.

Produktdaten produzieren … und verlieren

Der Händler setzt für die Logistik, Lagerwirtschaft und Bestellwesen auf ein zehnjähriges ERP, dass von einem regionalen Softwareanbieter programmiert worden war. Zum ERP gesellte sich in der jüngeren Vergangenheit ein Product Information Management System (PIM), dass eine bessere Bearbeitung der Artikeldaten ermöglichen sollte. Sowohl ERP als auch PIM spielen Produktdaten in den Webshop, aber es wurde versäumt dabei das führende System zu deklarieren. D.h. es sind entweder Daten aus dem PIM oder aus dem ERP korrekt, es kann aber nicht automatisch entschieden werden, welche Daten gültig sind.

Zudem war der Datenfluss zwischen den Systemen nicht exakt bestimmt, und niemand im Team konnte Auskunft geben, wer wann welche Artikeldaten in den Webshop spielt. So konnte es gut passieren, dass ein Redakteur Änderungen im PIM vornimmt, diese einen Moment später durch einen Cron Job aus dem ERP überschrieben werden. Aber kein Problem, der Redakteur muss ja nur die Daten neu publizieren, und schon ist wieder alles in Ordnung – wenn er es bemerkt…

Meiner Meinung nach müssen Daten nicht notwendigerweise vollständig über alle Systeme normalisiert werden, aber es sollte entscheidbar sein, welches die richtigen und aktuellen Daten sind.  Ausserdem sollten die Produktionsprozesse der Inhalte festgelegt und dokumentiert werden. Zu jeder Zeit sollte automatisch entscheidbar sein, welche Daten aktuell sind, und welche nicht. Da nun der Dienstleister für den neuen Shop keinen Auftrag hierfür hatte, wurde das Problem auch nicht gelöst.

Kompositionslücken

Gespannt war ich auf den Webshop, an dem sehr lange entwickelt worden war, und zwar auf Basis einer Open Source Technologie. Die Entwickler hatten den Shop durch ein proprietäres Framework ihrer Firma in verschiedene Bausteine geteilt. Die Bausteine produzieren “Portlets”, also HTML Fragmente, die dann über den sogenannten Composite Baustein zu einer Benutzeroberfläche für den Kunden komponiert wurden. Die Idee dahinter war sehr gut und ging in Richtung Microserivces: Die verschiedenen Dienste des Webshops als dedizierte Dienste unabhängig entwickeln und ausrollen zu können. Die Umsetzung wies aber substanzielle Mängel auf, hier einige Beispiele:

  1. Die Integration durch HTML Fragmente, die nur den Browser als Ausgabemedium zulässt, ist unzureichend geeignet, um verschiedene Endgeräte zu bespielen. Nachhaltigkeit in der Entwicklung ist nicht gegeben.
  2. Die Integration auf dem Server kostet Rechenzeit und Latenz, und ist nur günstig, wenn die Kunden ältere Mobiltelefone nutzen. Es wäre besser, wenn je nach Endgerät das UI auf dem Server oder auf dem Endgerät berechnet werden könnte, beispielsweise durch Einsatz von isomorphen JavaScript-Apps.
  3. Durch die Integration per HTML schwappen Concerns des Frontends, also der Präsentationsschicht, in die Backend Services. Dies macht die Services wesentlich komplexer, und damit teurer in Entwicklung und Unterhalt. Diese Integration sollte durch saubere APIs, auf Basis von GraphQL oder REST, ersetzt werden, um die Schichten entkoppeln zu können. Die saubere Entkopplung wird zu flexiblerer und günstigerer Wartung führen, denn das System wird sich insgesamt besser anpassen lassen.

Dekompositionen von Services sind gut für die Wartung und Entwicklung eines Systems. Dabei sollten Geschäftsdienste untereinander Domänenobjekte austauschen, und nicht ihre konkrete Repräsentation in einem Ausgabekanal, um die Kopplung zu verringern.

Durch die Verwendung eines proprietären Frameworks für die Komposition des UIs macht sich ein Dienstleister unsterblich. Nur er kann das Framework weiter entwickeln und Fehler beheben. Die Immaterialgüterrechte an den Bibliotheken waren nicht geklärt. Wenn solch ein Fall auftritt, dann sollte sich der Auftraggeber in jedem Fall diese Rechte an den Quelltexten und der Dokumentation sichern, auch wenn der Dienstleister sein Framework als Produkttechnologie bei mehreren Kunden im Einsatz hat. Es gibt zudem ausreichend viele, und  qualitativ hochwertige quelloffene Produkte am Markt, so dass genau geprüft werden sollte, ob es hier nicht eine bessere Alternative gibt.

Vertrauen Sie quelloffenen Lösungen mit aktiver Community und vielen Beiträgen. Proprietäre Softwaretechnologien weisen selten eine Qualität auf, wie Sie sie im OpenSource Bereich finden. Möchte ein Dienstleister heutzutage eigene, proprietäre Frameworks einsetzen, so kann dies ein Hinweis auf fehlende Kompetenz sein.

Fauxpas Geschäftsarchitektur

Auffällig bei der Modulkomposition war die Zerlegung des Shops nach Features, wie beispielsweise Import oder Export, aber nicht nach Domäne, denn es hatte keine Domänenanalyse gegeben. Die geschäftskritischen Funktionalitäten waren nach Features gruppiert und sukzessive entwickelt worden. Das ist im Prinzip kein Fehler, aber durchaus problematisch, denn die Features beziehen sich eben nur auf den einen Baustein des Shops. Darüber hinausgehende Betrachtungen, beispielsweise der Datenfluss vom ERP über das PIM in den Shop, wurden so nicht beachtet.

Für Retailer im B2C und B2B ist die Preisberechnung einer der wichtigsten, aber gleichzeitig auch schwierigsten Dienste überhaupt. Während im B2C meistens keine individuellen Kundenkonditionen gelten, und lediglich Aktionen, Coupons oder Mengenrabatte berücksichtigt werden müssen, sieht dies im B2B anders aus. Hier gibt es häufig kundenspezifische Konditionen, die berechnet werden müssen. Die Firma, deren System ich analysierte, war schon lange am Markt  und hatte viele individuelle Vereinbarungen mit Kunden. Bis zur Entwicklung des neuen Shops wurde die Preisberechnung im ERP und im alten Webshop durchgeführt. Eine Dokumentation der Geschäftsregeln für die Preisberechnung war nicht vorhanden und die Quelltexte der bestehenden Systeme undurchdringlich.

So wurden die Regeln vom Entwicklerteam erraten, und über lange Zeit Ausgaben des neuen Systems mit Ausgaben der alten Systeme manuell zur Prüfung der Korrektheit verglichen. Dabei wurden dann vor allem Fehler in den alten Systemen, beispielsweise bei der Mehrwertsteuerberechnung gefunden. Die bei diesem Vorgehen entstandenen Kosten waren gross, und ungeplant, und einer der Gründe, warum die Bewertung in Auftrag gegeben worden war.

Bruchstelle Anforderungen

Der Auftraggeber steht in der Pflicht dem Dienstleister seine Anforderungen state-of-the-art zu kommunizieren. Der Dienstleister steht lediglich in der Pflicht die Anforderungen mit seinen Arbeiten zu erfüllen, und auf dieser Basis sollten Verträge geschlossen werden. Bei SaaS Diensten sieht dies übrigens anders aus, da können Sie den Anbieter in die Pflicht nehmen, weil Sie keine Kontrolle über sein System haben.

Im vorliegenden Fall hatte es der Auftraggeber versäumt die Anforderungen zu erheben und diese an den Dienstleister delegiert. Dieser war nun nicht sonderlich gut darin, die Geschäftsprozesse und Regeln der Unternehmung zu kennen, denn es war nicht sein eigenes Geschäft. Unterm Strich sorgte dieses Versäumnis dann für den Projektverzug, und der Konflikt zwischen Auftraggeber und Dienstleister konnte durch diese Erkenntnis behoben werden.

Viele Organisationen verfügen nicht über die Methodenkompetenz zur strukturierten Erhebung von Anforderungen. In diesem Fall raten wir zur Erhebung und Dokumentation durch eine Drittfirma, aber möglichst nicht durch den Dienstleister selber, der für die Organisation das fragliche System bauen soll, weil ein Interessenkonflikt besteht.

Produktion

Als ich meinen Review durchführte, war das System nur noch wenige Wochen vom geplanten Go-Live entfernt, aber die Produktionsumgebung war noch nicht aufgebaut. Zwar stand der Dienstleister fest, jedoch war er vielen im Team noch nicht bekannt. Die für den Betrieb notwendigen Abklärungen zur künftigen Laufzeitumgebung konnten also nicht stattfinden, ebensowenig wie Last- und Performanceanalysen, oder ein Restoretest unter realen Bedingungen.

Ich empfehle wenigstens drei Monate vor Go-Live eines komplexen Systems mit Performancetests zu beginnen, um die Umgebungen rechtzeitig und korrekt einmessen zu können. Kürzt man diese Zeit auf wenige Wochen, so ist hierfür einfach nicht genügend Zeit. Wer sich vor bösen Überraschungen schützen möchte, der plant diese Tests ein, denn Hoffnung ist keine Strategie.

Fazit

Für viele Retailer ist der Shop das zentrale System, das über Umsatz und Erfolg entscheidet. Läuft der Shop nicht, weist eine schlechte Bedienbarkeit auf, oder ist langsam, so springen die Kunden reihenweise ab. Insbesondere im B2B müssen spezialisierte Funktionen und Anpassungen für die Kunden umgesetzt werden, um deren Supply Chain möglichst optimal zu unterstützen und so im Geschäft zu bleiben. Neben Performance, Sicherheit und Usability ist es also vor allem die Wartbarkeit bzw. Änderbarkeit, die Erfolge langfristig sichert.

Wenn Sie ein geschäftskritisches System beauftragen, so sollten Sie sich unbedingt im Klaren darüber sein, dass es sich um ihr eigenes System handelt, und nicht das System des Dienstleisters. Wenn in das System eingebrochen wird, und ihre Kundendaten im Netz landen, dann ist das einzig und allein ihr Problem.

Ich stelle fest, dass diese strategischen Aspekte der Systementwicklung nach wie vor wenig Beachtung finden. Viele Organisationen haben offensichtliche Kompetenzlücken im Bereich der übergreifenden Architektur im Zusammenspiel und der Anpassbarkeit ihrer sozio-technischen Systeme. Dies beginnt meiner Erfahrung nach schon bei der strukturierten Erfassung und Dokumentation der Services, Geschäftsprozesse, sowie der Geschäftsregeln, die die Analyse der Auswirkung von Veränderungen erst möglich machen. Liegen diese Informationen nicht vor, werden Änderungen zum Russisch Roulette: Wer die Trommel falsch dreht, schiesst sich die eigenen Systeme ab und verbaut sich künftige Möglichkeiten.

Achten Sie also darauf, dass Sie sich einen Überblick verschaffen und Ihre Unternehmensprozesse vernünftig dokumentiert sind, um Risiken strukturiert begegnen zu können. Die Silberrücken AG bietet die Begleitung von Dokumentation und Entwicklung von Unternehmensarchitekturen als Teil ihres Kerngeschäfts an. Wir helfen Ihnen bei der strategischen Planung und beim Schliessen von Verträgen. Gerne steuern und überwachen wir für Sie wichtige Entwicklungsprojekte. Fragen Sie uns unverbindlich:  wir helfen gerne.

Kommentar verfassen