CRUD Geschäftsanwendungen

Seit den 1980er Jahren haben die überwiegende Zahl der Geschäftsanwendungen ein ähnliches internes Design angenommen, 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 bedeutende technologische Sprünge überstanden, von Konsolenterminals, die an Mainframes angeschlossen waren, bis hin zu mobilen Apps, die mit Cloud-Plattformen verbunden sind. Das Verständnis des CRUD-Designs ist in komplexen Bereichen – wie supply chain – wichtig, die in der Regel auf einer gesamten anwendungsbezogenen Landschaft von CRUD-Anwendungen operieren. Ein solches Verständnis ist entscheidend, um diese Landschaft angemessen zu navigieren, von den Verhandlungen mit Softwareanbieter bis hin zur Auswertung der in all diesen Anwendungen erfassten Datensätze.

Überblick

Bereits in den frühen 1980er Jahren hatten sich relationale Datenbanken als die vorherrschende Methode zur Speicherung und zum Abruf von Geschäftsdaten etabliert. Ende der 1990er Jahre hatten aufkommende Open-Source-relationale Datenbanken diese Praxis weiter gefestigt. Heutzutage bildet das CRUD-Design den am weitesten verbreiteten Ansatz zur Entwicklung einer Geschäftsanwendung auf Basis einer relationalen Datenbank ab.

Eine Datenbank im relationalen Sinne umfasst eine Liste von Tabellen. Jede Tabelle enthält eine Liste von Spalten (auch als Felder bezeichnet). Jede Spalte besitzt einen Datentyp: Zahl, Text, Datum etc. Eine Tabelle enthält eine Liste von Zeilen (auch Reihen genannt). In der Regel wird erwartet, dass die Anzahl der Spalten begrenzt bleibt – höchstens einige hundert –, während die Anzahl der Zeilen unbegrenzt ist und potenziell Milliarden erreichen kann.

Abbildung 1: Eine einfache Tabelle, die eine Liste von Produkten und deren Lagerbestandssituation darstellt und typisch dafür ist, was man in einer relationalen Datenbank findet.

In der Praxis erfordert der relationale Ansatz mehrere Tabellen, um betriebsrelevante Sachverhalte (z. B. Bestellungen) abzubilden. 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 „Warenkorb“-Entität, bestehend aus zwei Tabellen. Diese Entität spiegelt den Zustand des Warenkorbs für den Besucher einer E-Commerce-Website wider.

Wie oben erwähnt, steht CRUD für Create, Read, Update und Delete, die 4 grundlegenden Operationen, die an Tabellen innerhalb einer relationalen Datenbank durchgeführt werden.

• Create: Füge der Tabelle neue Zeilen hinzu.
• Read: Lese bestehende Zeilen aus der Tabelle aus.
• Update: Ändere bestehende Zeilen in der Tabelle.
• Delete: Lösche bestehende Zeilen aus der Tabelle.

Diese Operationen werden heutzutage fast immer mithilfe einer speziellen Datenbanksprache, in der Regel einem SQL-(Structured Query Language)-Dialekt¹, durchgeführt.

Das CRUD-Design besteht darin, Entitäten zusammen mit ihren Benutzeroberflächen-Pendants einzuführen, die üblicherweise als „Screens“ bezeichnet werden. Ein Screen, der auch eine Webseite sein kann, bietet in der Regel die 4 Operationen für die betreffende Entität.

Der überwiegende Teil der „transaktionalen“ Geschäftsanwendungen, von einem einfachen Zeiterfassungstool bis hin zu einem sehr komplexen ERP oder CRM, verwendet im Hintergrund ein ähnliches CRUD-Design – ein Designmuster, das vor mehr als 4 Jahrzehnten etabliert wurde. Einfache Anwendungen umfassen nur wenige Entitäten, während komplexe Anwendungen tausende von ihnen enthalten können. Doch von einfach bis komplex, was das grundlegende Design betrifft, ist es im Grunde genommen mehr vom Gleichen.

Die Vielfalt an Benutzeroberflächen, wie sie bei Geschäftsanwendungen zu finden ist, mag trügerisch erscheinen, da es so wirkt, als hätten die Anwendungen wenig gemeinsam. In der Praxis besitzen jedoch die meisten Anwendungen ein nahezu identisches inneres Design, das auf dem CRUD-Prinzip basiert.

CRUD-Anwendungen in supply chain

Fast alle Anwendungen (die den Endanwendern zugänglich gemacht werden), die zur Steuerung von Unternehmen und deren Prozessen eingesetzt werden, sind CRUD. Allgemein gesprochen, wenn ein Stück Unternehmenssoftware von einem 3-Buchstaben-Akronym wie ERP, MRP, CRM, SRM, PLM, PIM, WMS, OMS, EDI (usw.) profitiert, wird es 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 nutzt die IT-Abteilung eine Vielzahl von Technologien, die nicht CRUD sind: Netzwerke, Virtualisierung, Systemadministrationstools etc. Diese Technologien bleiben jedoch für die Endanwender größtenteils unsichtbar oder zumindest unaufdringlich.

Solche CRUD-Anwendungen enthalten nahezu alle relevanten historischen Transaktionsdaten, die genutzt werden können, um die supply chain quantitativ zu verbessern (zum Beispiel durch Optimierung der Lagerbestände). Infolgedessen versuchen viele CRUD-Anwendungen² zu einem gewissen Zeitpunkt, sich in analytische Fähigkeiten zu verzweigen (etwa für Planungs- oder Optimierungszwecke). Leider bringt CRUD, obwohl es zahlreiche Vorteile bietet, auch erhebliche Nachteile in Bezug auf analytische Kapazitäten mit sich (siehe unten „Die Grenzen von CRUD“).

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. Infolgedessen ist der technologische Weg außergewöhnlich gut definiert. Darüber hinaus profitiert CRUD auch von hochwertigen Entwicklungstools, sodass die Produktivität der Softwareentwickler, die an einer auf CRUD basierenden Anwendung arbeiten, in der Regel hoch ist.

Aus personeller Sicht gibt es einen großen Markt an Softwareentwicklern, die Erfahrung mit CRUD haben. Darüber hinaus gehört CRUD zu den zugänglichsten Bereichen der Softwareentwicklung – vor allem aufgrund der hochwertigen Entwicklungstools. Folglich ist CRUD selbst für Junior-Softwareentwickler (und weniger talentierte Senior-Entwickler) äußerst zugänglich. Da die zugrunde liegenden CRUD-Prinzipien seit Jahrzehnten stabil sind, kann der Übergang zu einem neueren Technologie-Stack relativ problemlos erfolgen – zumindest im Vergleich zu anderen, technisch anspruchsvolleren Ansätzen.

Schließlich bietet CRUD aus Sicht der Geschäftskontinuität all die Vorteile, die seine zugrunde liegende relationale Datenbank mit sich bringt. Zum Beispiel bleiben die Daten zugänglich, solange die Datenbank für das Kundenunternehmen erreichbar ist; dies gilt selbst dann, wenn der ursprüngliche Anbieter der CRUD-Anwendung nicht mehr operativ oder kooperativ mit dem Kundenunternehmen zusammenarbeitet. Selbst in diesem Extremfall ist der Datenzugriff durch moderate Reverse-Engineering-Maßnahmen erreichbar.

Die Grenzen von CRUD

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

Die Einschränkung in der Ausdrucksfähigkeit spiegelt die Tatsache wider, dass die vier Aktionen (oder „Verben“) – create, read, update und delete – nicht in der Lage sind, eine feinere Palette von Intentionen adäquat abzubilden. Beispielsweise betrachten Sie eine Situation, in der ein Mitarbeiter versucht, mehrere fehlerhaft erstellte Lieferanteneinträge im SRM (Supplier Relationship Manager) zu deduplizieren. Das passende Verb für diesen Vorgang wäre merge. Das CRUD-Design kennt dieses Verb jedoch nicht. Tatsächlich wird eine solche Funktionalität fast immer als zweistufiger Prozess implementiert. Zunächst werden alle Zeilen aktualisiert, die bisher auf die Lieferanteneinträge zeigten, die bald gelöscht werden sollen, sodass sie nun auf den zu erhaltenden Eintrag verweisen. Anschließend werden alle bis auf einen der zusätzlichen Lieferanteneinträge gelöscht. Dadurch geht nicht nur die ursprüngliche Intention (das merge) verloren, sondern die Transformation erfolgt zudem destruktiv in Bezug auf die Daten. Anekdotisch zeigt sich, dass wenn CRUD-Anwendungen ihre Nutzer warnen, dass sie dabei sind, irreversible Änderungen an den Daten vorzunehmen, dies fast immer auf eine Einschränkung des CRUD zurückzuführen ist³, die in das Nutzererlebnis eingreift.

Die Leistungseinschränkung spiegelt die Tatsache wider, dass jede lang andauernde Operation – also jede, die mehr als einen winzigen Bruchteil der Datenbank liest – die CRUD-Anwendung in Gefahr bringt, nicht mehr zu reagieren. Tatsächlich erwarten Endnutzer, dass sich die Latenz bei nahezu allen alltäglichen Operationen kaum bemerkbar macht. Zum Beispiel sollte die Aktualisierung eines Stock Level im WMS (Warehouse Management System) in Millisekunden erfolgen, um einen reibungslosen Betrieb zu gewährleisten. Da alle an der CRUD-Anwendung ausgeführten Operationen Rechenressourcen der gleichen zugrunde liegenden relationalen Datenbank beanspruchen, bringt nahezu jede nicht-triviale Operation diesen Kern in Gefahr, von Rechenressourcen abgeschnitten zu werden. Anekdotisch führt dies in großen Unternehmen häufig dazu, dass CRUD-Anwendungen für Sekunden (oder sogar Minuten) nicht mehr reagieren. Diese Situationen werden fast immer durch einige „schwere“ Operationen verursacht, die kurzfristig die Rechenressourcen monopolisieren und dadurch alle anderen Operationen verzögern – einschließlich der „leichten“ Operationen. Dieses Problem erklärt, warum nicht-triviale Operationen üblicherweise in Batch-Jobs ausgelagert werden, die nachts ausgeführt werden. Es erklärt auch, warum CRUD-Anwendungen in der Regel bei der Analyse versagen, da sich analytische Arbeitslasten praktisch nur außerhalb der Bürozeiten ausführen lassen.

Moderne CRUD-Varianten

In den letzten Jahrzehnten hat sich Unternehmenssoftware erheblich weiterentwickelt. In den 1990er Jahren wechselten die meisten Anwendungen von Konsolenterminals zu Desktop-Benutzeroberflächen. In den 2000er Jahren erfolgte der Wechsel von Desktop- zu Web-Benutzeroberflächen. In etwa dem letzten Jahrzehnt haben sich die meisten Anwendungen zu SaaS (Software as a Service) entwickelt und sind dabei in Richtung cloud computing migriert. Dennoch blieb das CRUD-Design von diesen Entwicklungen weitgehend unberührt.

Der Übergang von Single-Tenancy zu Multi-Tenancy⁴ zwang Softwareanbieter dazu, den Datenzugriff auf Entitäten hinter APIs (Application Programming Interfaces) zu verbergen. Tatsächlich birgt direkter Datenbankzugriff, selbst wenn er nur lesend erfolgt, die Gefahr, dass die Rechenressourcen des Transaktionskerns durch nur eine kleine Anzahl schwerer Anfragen ausgehöhlt werden. Die API mildert diese Probleme. Die Absicherung des Zugriffs auf die Anwendungsdaten hinter einer API negiert zudem einige der CRUD-Vorteile, zumindest aus Sicht des Kundenunternehmens. Zuverlässiges Extrahieren großer Datenmengen 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 möglicherweise nicht alle in der Anwendung vorhandenen Daten preis –, obwohl der direkte Datenbankzugriff von Haus aus vollständigen Zugang zu den Daten gewährt haben sollte.

Die wesentliche Weiterentwicklung von CRUD zeigt sich in den Tools. In den 2010er Jahren entstanden eine Vielzahl hochwertiger Open-Source-Ökosysteme zur Unterstützung der Entwicklung von CRUD-Anwendungen. Diese Ökosysteme haben die Entwicklung von CRUD-Anwendungen stark standardisiert, wodurch der dafür benötigte Qualifikationsaufwand deutlich gesenkt und die Reibungsverluste im Entwicklungsprozess reduziert wurden.

Dynamik der Anbieter

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

Durch das Hinzufügen von Entitäten werden neue Funktionen freigeschaltet, und der Anbieter erhält die Möglichkeit, seine Preise zu erhöhen, was den zusätzlichen für das Kundenunternehmen geschaffenen Mehrwert widerspiegelt. Außerdem werden Module⁵, also Gruppierungen betriebsrelevanter Entitäten, häufig als Preissteuerungsmechanismus eingeführt, um mehr zu verlangen (je nach Umfang der Nutzung des Softwareprodukts).

Infolgedessen neigen CRUD-Anwendungen dazu, im Laufe der Zeit komplexer, aber gleichzeitig weniger relevant zu werden. Tatsächlich sind, wenn neue Entitäten hinzugefügt werden, um den Interessen der gesamten Kundenbasis zu dienen, viele (wenn nicht sogar die meisten) der neu eingeführten Entitäten für kein einzelnes Kundenunternehmen relevant. Diese „toten“ Entitäten – aus Sicht des Kundenunternehmens – stellen eine wachsende, unbeabsichtigte Komplexität dar, die das CRUD verunreinigt.

Als SaaS verkaufte CRUD-Anwendungen neigen dazu, mit zunehmender Funktionalität und Bekanntheit teurer zu werden. Da es jedoch nur wenige Markteintrittsbarrieren⁶ gibt, tauchen häufig neue Anbieter auf, die sich auf Anwendungsfälle zu deutlich niedrigeren Preisen konzentrieren – und der Kreis schließt sich ad infinitum.

Lokads Sichtweise

Viele, wenn nicht die meisten, große Unternehmen unterschätzen das Ausmaß der Kommodifizierung von CRUD-Anwendungen. Für die meisten Anbieter von Unternehmenssoftware, die sie verkaufen, machen die Entwicklungskosten nur einen winzigen Bruchteil der Gesamtausgaben des Unternehmens aus, weit entfernt von den Kosten, die mit Marketing und Vertrieb der Anwendungen verbunden sind. Insbesondere verlagern Anbieter, die CRUD-Anwendungen entwickeln, häufig ihre Engineering-Teams in Niedriglohnländer, da der CRUD-Ansatz (aufgrund seiner allgemeinen Zugänglichkeit) eine weniger talentierte – und günstigere – Engineering-Belegschaft verkraften kann.

Heutzutage gibt es kaum Gründe, enorme Summen für CRUD-Anwendungen zu zahlen. Als Faustregel gilt: Jede CRUD-Anwendung, die über 250k USD pro Jahr kostet, ist ein ernsthafter Kandidat für eine Ersatzlösung durch unternehmenseigene Software. Jede CRUD-Anwendung, die über 2.5M USD pro Jahr kostet, sollte fast zwangsläufig durch unternehmenseigene Software ersetzt werden (möglicherweise beginnend mit einer bereits vorhandenen Open-Source-Basis, die anschließend angepasst wird).

Anbieter von Unternehmenssoftware, die CRUD-Anwendungen verkaufen, sind sich dieses Problems sehr wohl bewusst (und das schon seit Langem). Daher ist es verlockend für den Anbieter, nicht-CRUD Funktionalitäten/Anwendungen/Elemente⁷ in die Lösung zu integrieren und zu versuchen, die Kunden davon zu überzeugen, (a) dass diese Elemente wichtig sind und (b) dass diese Elemente eine Art „geheime Zutat“ darstellen, die der Kunde nicht reproduzieren kann. Dieser Ansatz gelingt jedoch fast nie, hauptsächlich weil der Anbieter nicht über die richtige Engineering-DNA⁸ verfügt. Anekdotisch zeigt sich, dass nahezu alle namhaften und etablierten ERPs umfangreiche Prognose- und Planungskapazitäten besitzen, von denen fast alle weitgehend ungenutzt bleiben, weil sie diese Aufgaben nur unzureichend erfüllen.

Lokad ist ein Anbieter von Unternehmenssoftware, der sich auf die prädiktive Optimierung der supply chain spezialisiert. Unsere Technologie wurde entwickelt, um historische Transaktionsdaten zu nutzen – jener Art, die aus den CRUD-Apps extrahiert werden können, welche die täglichen Abläufe eines Unternehmens unterstützen. Allerdings ist Lokad selbst keine CRUD-App. Unsere Produktionsumgebung beinhaltet nicht einmal eine relationale Datenbank. Während CRUD eine gültige technologische Antwort auf das Management der transaktionalen Workflows eines Unternehmens darstellt, ist sie für die prädiktive Modellierung oder mathematische Optimierung einer supply chain überhaupt nicht relevant.

Notizen