CRUD Business Apps

Seit den 1980er Jahren hat die überwiegende Mehrheit der Unternehmensanwendungen ein ähnliches internes Design übernommen, nämlich CRUD, was für Create / Read / Update / Delete steht. Dieses Design spiegelt die Verwendung einer relationalen Datenbank zur Speicherung der Geschäftsdaten wider. Das CRUD-Design hat mehrere große technologische Fortschritte überstanden, von Konsolenterminals, die mit Großrechnern verbunden sind, bis hin zu mobilen Apps, die mit Cloud-Plattformen verbunden sind. Das Verständnis des CRUD-Designs ist in komplexen Bereichen wie der Supply Chain von Bedeutung, die in der Regel auf einer gesamten Anwendungslandschaft aus CRUD-Apps arbeiten. Diese Erkenntnis ist entscheidend, um sich in dieser Landschaft richtig zu bewegen, sei es bei Verhandlungen mit Softwareanbietern oder bei der Nutzung der in all diesen Apps gesammelten Dateneinträge.

Überblick

Anfang der 1980er Jahre hatten sich relationale Datenbanken als dominanter Ansatz zur Speicherung und zum Zugriff auf Geschäftsdaten etabliert. Ende der 1990er Jahre hatten aufkommende Open-Source-relationale Datenbanken diese Praxis weiter gefestigt. Heutzutage spiegelt das CRUD-Design den am weitesten verbreiteten Ansatz zur Entwicklung einer Unternehmensanwendung auf Basis einer relationalen Datenbank wider.

Eine Datenbank im relationalen Sinne umfasst eine Liste von Tabellen. Jede Tabelle enthält eine Liste von Spalten (auch als Felder bezeichnet). Jedes Feld hat einen Datentyp: Zahl, Text, Datum usw. Eine Tabelle enthält eine Liste von Zeilen (auch als Datensätze bezeichnet). Als Faustregel gilt, dass die Anzahl der Spalten begrenzt bleibt, höchstens einige Hundert, während die Anzahl der Zeilen unbegrenzt ist und möglicherweise Milliarden erreichen kann.

Abbildung 1: Eine einfache Tabelle, die eine Liste von Produkten und ihrer Lagerbestandssituation widerspiegelt, veranschaulicht typischerweise das, was man in einer relationalen Datenbank findet.

In der Praxis erfordert der relationale Ansatz mehrere Tabellen, um etwas von geschäftlichem Interesse abzubilden (z. B. Bestellungen). Diese “Gruppierungen” von Tabellen werden als Entitäten bezeichnet. Eine Entität spiegelt das übergeordnete Verständnis des Geschäfts wider.

Abbildung 2: Eine einfache "Einkaufswagen"-Entität, bestehend aus zwei Tabellen. Diese Entität spiegelt den Zustand des Einkaufswagens für den Besucher einer E-Commerce-Website wider.

Wie oben erwähnt, bezieht sich CRUD auf Create, Read, Update und Delete, die 4 grundlegenden Operationen, die auf Tabellen in einer relationalen Datenbank durchgeführt werden sollen.

• Create: neue Zeilen zur Tabelle hinzufügen.
• Read: vorhandene Zeilen aus der Tabelle abrufen.
• Update: vorhandene Zeilen in der Tabelle ändern.
• Delete: vorhandene Zeilen aus der Tabelle löschen.

Diese Operationen werden über eine dedizierte Datenbanksprache durchgeführt, heutzutage fast immer ein SQL (Structured Query Language) Dialekt¹.

Das CRUD-Design besteht darin, Entitäten zusammen mit ihren Benutzeroberflächen-Gegenstücken einzuführen, die in der Regel als “Bildschirme” bezeichnet werden. Ein Bildschirm, der eine Webseite sein kann, enthält in der Regel die 4 Operationen für die interessierende Entität.

Die überwiegende Mehrheit der “transaktionalen” Geschäftsanwendungen, von einem einfachen Zeiterfassungssystem bis hin zu einem sehr komplexen ERP oder CRM, verwendet unter der Haube ein ähnliches CRUD-Design - ein vor mehr als 4 Jahrzehnten etabliertes Designmuster. Einfache Anwendungen enthalten nur wenige Entitäten, während komplexe Anwendungen Tausende von ihnen enthalten können. In Bezug auf das inhärente Design handelt es sich jedoch von einfach bis komplex um mehr oder weniger dasselbe.

Die Vielfalt der Benutzeroberflächen, wie sie bei Geschäftsanwendungen zu finden sind, kann täuschen, da es scheint, als hätten die Anwendungen sehr wenig gemeinsam. In der Praxis haben die meisten Anwendungen jedoch ein nahezu identisches internes Design, das mit der CRUD-Perspektive übereinstimmt.

CRUD-Anwendungen in der Supply Chain

Nahezu alle (den Endbenutzern zugänglichen) Anwendungen, die zur Steuerung von Unternehmen und ihren Prozessen verwendet werden, sind CRUD-Anwendungen. Allgemein gesprochen, wenn eine Unternehmenssoftware von einer 3-Buchstaben-Abkürzung wie ERP, MRP, CRM, SRM, PLM, PIM, WMS, OMS, EDI (usw.) profitiert, dann wird sie fast immer als CRUD implementiert. Die bemerkenswerteste Ausnahme von dieser Regel sind Dokumenteneditoren (z. B. Tabellenkalkulationssoftware), die eine völlig andere Art von Softwaretechnologie darstellen.

Intern verwendet die IT-Abteilung eine Vielzahl von Technologien, die nicht CRUD sind: Netzwerke, Virtualisierung, Sysadmin-Tools usw. Diese Technologien sind jedoch für Endbenutzer weitgehend unsichtbar oder zumindest unauffällig.

Solche CRUD-Anwendungen enthalten nahezu alle relevanten historischen Transaktionsdaten, die zur quantitativen Verbesserung der Supply Chain genutzt werden können (z. B. Optimierung der Lagerbestände). Aus diesem Grund versuchen viele CRUD-Anwendungen² zu einem bestimmten Zeitpunkt, analytische Funktionen zu integrieren (z. B. für Planungs- oder Optimierungszwecke). Leider weist CRUD neben zahlreichen Vorteilen auch brutale Mängel hinsichtlich analytischer Fähigkeiten auf (siehe “Die Grenzen von CRUD” unten).

Die Vorteile von CRUD

CRUD ist seit Jahrzehnten der bevorzugte Ansatz für Geschäftsanwendungen. Aus technologischer Sicht profitiert dieser Ansatz von umfassenden Open-Source-Frameworks und -Tools in allen wichtigen Software-Stacks. Dadurch ist der technologische Weg außergewöhnlich gut definiert. Darüber hinaus profitiert CRUD auch von hochwertigen Entwicklungstools, wodurch die Produktivität der Softwareingenieure, die an der Entwicklung einer CRUD-basierten Anwendung beteiligt sind, tendenziell hoch ist.

Aus Sicht des Personals gibt es einen großen Markt für Softwareingenieure, die Erfahrung mit CRUD haben. Darüber hinaus ist CRUD einer der zugänglichsten Teile der Softwareentwicklung - hauptsächlich aufgrund seiner hochwertigen Entwicklungstools. Daher ist CRUD selbst für Junior-Softwareingenieure (und weniger talentierte erfahrene Softwareingenieure) äußerst zugänglich. Da die zugrunde liegenden CRUD-Prinzipien seit Jahrzehnten stabil sind, kann auch der Übergang zu einem neueren technologischen Stack relativ problemlos erfolgen - zumindest im Vergleich zu anderen, technisch versierteren Ansätzen.

Schließlich bietet CRUD aus Sicht der Geschäftskontinuität alle Vorteile, die mit der zugrunde liegenden relationalen Datenbank verbunden sind. Solange die Datenbank für das Kundenunternehmen zugänglich ist, bleiben die Daten zugänglich. Dies gilt auch dann, wenn der ursprüngliche Anbieter der CRUD-Anwendung nicht mehr operativ oder kooperativ mit dem Kundenunternehmen ist. Selbst in diesem Extremfall kann der Zugriff auf die Daten durch bescheidene Reverse-Engineering-Bemühungen erreicht werden.

Die Grenzen von CRUD

CRUD-Anwendungen stoßen auf inhärente Einschränkungen, die mit der Art und Weise zusammenhängen, wie sie die relationale Datenbank intern nutzen. Diese Einschränkungen können nicht umgangen werden, ohne die mit CRUD verbundenen Vorteile grundlegend aufzugeben. Diese Einschränkungen lassen sich in zwei Hauptkategorien einteilen: Ausdrucksfähigkeit und Leistung.

Die Einschränkung der Ausdrucksfähigkeit spiegelt die Tatsache wider, dass die vier Aktionen (oder “Verben”) - erstellen, lesen, aktualisieren und löschen - nicht angemessen eine granulare Vielzahl von Absichten erfassen können. Betrachten wir zum Beispiel eine Situation, in der ein Mitarbeiter mehrere Lieferanteneinträge, die versehentlich im SRM (Supplier Relationship Manager) erstellt wurden, zusammenführen möchte. Das geeignete Verb für diese Operation wäre “zusammenführen”. Das CRUD-Design hat jedoch dieses Verb nicht. Tatsächlich wird eine solche Funktion in der Regel als zweistufiger Prozess implementiert. Zuerst werden alle Zeilen aktualisiert, die auf die bald zu löschenden Lieferanteneinträge verweisen, sodass sie nun auf den zu erhaltenden Eintrag verweisen. Zweitens werden alle zusätzlichen Lieferanteneinträge bis auf einen gelöscht. Dabei geht nicht nur die ursprüngliche Absicht (die Zusammenführung) verloren, sondern die Transformation ist auch datenzerstörend. Anekdotisch gesehen ist es fast immer eine CRUD-Einschränkung³, die sich in die Benutzererfahrung einmischt, wenn CRUD-Anwendungen ihre Benutzer davor warnen, dass sie eine irreversible Änderung an den Daten vornehmen werden.

Die Leistungseinschränkung spiegelt die Tatsache wider, dass jede lang laufende Operation - das heißt, jede Operation, die mehr als einen winzigen Bruchteil der Datenbank liest - die CRUD-Anwendung gefährdet, unresponsive zu werden. Tatsächlich erwarten Endbenutzer für eine CRUD-Anwendung, dass die Latenzzeit bei nahezu allen alltäglichen Operationen kaum spürbar ist. Das Aktualisieren eines Lagerbestands im WMS (Warehouse Management System) sollte in Millisekunden erfolgen (um einen reibungslosen Ablauf der Operationen zu gewährleisten). Da alle Operationen, die an die CRUD-Anwendung übergeben werden, Rechenressourcen aus derselben zugrunde liegenden relationalen Datenbank verbrauchen, setzt fast jede nicht-triviale Operation den Kern dieser Datenbank einem Risiko aus, von Rechenressourcen ausgehungert zu werden. Anekdotisch gesehen werden CRUD-Anwendungen in großen Unternehmen häufig für Sekunden (sogar Minuten) unresponsive. Diese Situationen werden fast immer durch einige “schwere” Operationen verursacht, die kurzzeitig alle Rechenressourcen monopolisieren und somit alle anderen Operationen - einschließlich der “leichten” - verzögern. Dieses Problem erklärt, warum nicht-triviale Operationen normalerweise in Batch-Jobs aufgeteilt werden, die nachts ausgeführt werden. Es erklärt auch, warum CRUD-Anwendungen in der Regel schlecht für Analysen geeignet sind, da analytische Workloads praktisch nur außerhalb der Bürozeiten ausgeführt werden können.

Moderne CRUD-Varianten

In den letzten Jahrzehnten hat die Unternehmenssoftware erhebliche Entwicklungen durchlaufen. In den 1990er Jahren haben die meisten Anwendungen von Konsolenterminals auf Desktop-Benutzeroberflächen aufgerüstet. In den 2000er Jahren haben die meisten Anwendungen von Desktop-Benutzeroberflächen auf Web-Benutzeroberflächen aufgerüstet. In den letzten zehn Jahren haben die meisten Anwendungen auf SaaS (Software as a Service) umgestellt und sich dabei in Richtung Cloud Computing bewegt. Das CRUD-Design blieb jedoch von diesen Entwicklungen weitgehend unberührt.

Der Übergang von Einzelmandanten zu Mehrmandanten⁴ zwang Softwareanbieter dazu, den Zugriff auf Daten über APIs (Application Programming Interfaces) zu steuern. Tatsächlich kann der direkte Zugriff auf die Datenbank, auch wenn er nur lesend ist, dazu führen, dass die Rechenressourcen des Transaktionskerns durch nur eine geringe Anzahl von schweren Anfragen erschöpft werden. Die API mildert diese Art von Problemen. Der Zugriff auf die App-Daten über eine API hebt auch einige der Vorteile von CRUD auf, zumindest aus Sicht des Kundenunternehmens. Das zuverlässige Extrahieren einer großen Menge an Daten aus einer API erfordert in der Regel mehr Aufwand als das Erstellen einer vergleichbaren Reihe von SQL-Abfragen. Darüber hinaus kann die API unvollständig sein - sie gibt Daten nicht frei, die in der App vorhanden sind -, obwohl die direkte Datenbank den vollständigen Zugriff auf die Daten von Design her ermöglichen sollte.

Die Hauptentwicklung von CRUD findet in den Werkzeugen statt. In den 2010er Jahren entstanden eine Vielzahl hochwertiger Open-Source-Ökosysteme, die die Entwicklung von CRUD-Anwendungen unterstützen. Diese Ökosysteme haben die Entwicklung von CRUD-Anwendungen umfassend standardisiert und damit die für ihre Entwicklung erforderlichen Fähigkeiten erheblich reduziert und die mit dem Entwicklungsprozess verbundenen Reibungsverluste verringert.

Anbieterdynamik

Die Entwicklungskosten einer CRUD-Anwendung werden weitgehend durch die Anzahl der Entitäten bestimmt. Je mehr Entitäten vorhanden sind, desto mehr Bildschirme müssen entwickelt, dokumentiert und gewartet werden. Daher besteht der natürliche Weg für einen Softwareanbieter, der eine CRUD-Anwendung bewirbt, darin, mit einer begrenzten Anzahl von Entitäten zu beginnen und im Laufe der Zeit weitere hinzuzufügen.

Das Hinzufügen von Entitäten schaltet neue Funktionen frei und gibt dem Anbieter die Möglichkeit, seine Preise zu erhöhen, um den zusätzlichen Wert für das Kundenunternehmen widerzuspiegeln. Darüber hinaus werden häufig Module⁵, d.h. Gruppierungen von geschäftsbezogenen Entitäten, als Preismechanismus eingeführt, um mehr zu berechnen (abhängig vom Umfang der Nutzung des Softwareprodukts).

Als Ergebnis neigen CRUD-Anwendungen im Laufe der Zeit dazu, komplexer, aber auch weniger relevant zu werden. Tatsächlich sind viele (wenn nicht die meisten) der neu eingeführten Entitäten, die dem Interesse der gesamten Kundenbasis dienen, für jedes individuelle Kundenunternehmen nicht relevant. Diese “toten” Entitäten - aus Sicht des Kundenunternehmens - stellen eine wachsende zufällige Komplexität dar, die das CRUD verschmutzt.

CRUD-Anwendungen, die als SaaS verkauft werden, werden tendenziell teurer, je mehr Funktionen und Bekanntheit sie erlangen. Da es jedoch sehr wenige Markteintrittsbarrieren gibt⁶, tauchen häufig neue Anbieter auf, die sich auf Anwendungsfälle mit wesentlich niedrigeren Preisen konzentrieren - und der Zyklus wiederholt sich ad infinitum.

Lokads Standpunkt

Viele, wenn nicht die meisten, große Unternehmen unterschätzen das Ausmaß der Standardisierung von CRUD-Anwendungen. Für die meisten Softwareanbieter, die sie verkaufen, sind die Entwicklungskosten nur ein winziger Bruchteil der Gesamtausgaben des Unternehmens, weit hinter den Kosten für Marketing und Vertrieb der Anwendungen selbst. Insbesondere Softwareanbieter, die CRUD-Anwendungen entwickeln, verlagern ihre Entwicklungsteams häufig in kostengünstige Länder, da der CRUD-Ansatz (aufgrund seiner allgemeinen Zugänglichkeit) eine weniger talentierte - und weniger teure - Entwicklungsbelegschaft tolerieren kann.

Es gibt heutzutage sehr wenig Grund, hohe Beträge für CRUD-Anwendungen zu zahlen. Als Faustregel gilt: Jede CRUD-Anwendung, die mehr als 250.000 USD pro Jahr kostet, ist ein ernsthafter Kandidat für eine interne Softwareersetzung. Jede CRUD-Anwendung, die mehr als 2,5 Millionen USD pro Jahr kostet, sollte fast immer durch interne Software ersetzt werden (möglicherweise ausgehend von einer vorhandenen Open-Source-Basis und Anpassung von dort aus).

Unternehmen, die CRUD-Anwendungen verkaufen, sind sich dieses Problems nur allzu bewusst (und das schon seit langem). Daher ist es für den Anbieter verlockend, Nicht-CRUD-Funktionalitäten/Apps/Elemente⁷ in die Lösung aufzunehmen und die Kunden davon zu überzeugen, dass diese Teile wichtig sind und dass sie eine Art “Geheimrezept” darstellen, das der Kunde nicht replizieren kann. Dieser Ansatz hat jedoch fast nie Erfolg, hauptsächlich weil dem Anbieter das richtige Engineering-DNA⁸ fehlt. Als belegende Anekdote haben fast alle bekannten und etablierten ERP-Systeme umfangreiche Prognose- und Planungsfunktionen, von denen jedoch die meisten kaum genutzt werden, da sie diese Aufgaben tatsächlich schlecht erfüllen.

Lokad ist ein Softwareanbieter, der auf die prädiktive Optimierung der Supply Chain spezialisiert ist. Unsere Technologie wurde entwickelt, um historische Transaktionsdaten zu nutzen - die Art von Daten, die aus den CRUD-Anwendungen extrahiert werden können, die die täglichen Geschäftsvorgänge eines Unternehmens unterstützen. Lokad selbst ist jedoch keine CRUD-Anwendung. Unsere Produktionsumgebung enthält nicht einmal eine relationale Datenbank. Während CRUD eine gültige technologische Antwort für das Management der transaktionalen Workflows eines Unternehmens ist, hat es keinerlei Relevanz für die prädiktive Modellierung oder mathematische Optimierung einer Supply Chain.

Anmerkungen