Die Zukunft datenbankzentrierter IT-Architekturen

Aktuelle IT-Landschaften sind nach wie vor von einer großen Anzahl datenbankzentrierter Architekturen geprägt. Dabei handelt es sich nicht nur um Legacy-Systeme aus der Zeit des Mainframes, sondern auch um viele moderne IT-Architekturen. Ist das alles noch zeitgemäß? Müssen wir etwas tun und, wenn ja, wie könnten alternative Lösungen aussehen?

Ausgangslage

Dass es so viele datenbankzentrierte Lösungen gibt, hat in erster Linie historische Gründe, da die großen Datenbankhersteller IBM (DB2) und Oracle über viele Jahre Marktführer bei den relationalen Datenbanksystemen waren. Relationale Datenbanksysteme haben den Charme, dass diese Technologie weit verbreitet ist und das Wissen und der Umgang mit diesen Datenbanksystemen zur Commodity gezählt werden kann. Sie sind performant, unterstützen Transaktionen, sind in der Lage, riesige Datenmengen zu verwalten, und haben mit SQL eine genormte Abfragesprache. In vielen Fällen ist die Infrastruktur auf diese Datenbanksysteme ausgerichtet, und diese Investitionen möchte man nicht umsonst getätigt haben.

Datenbankzentrierte Architektur

Wie wir alle wissen, hat diese Strategie auch die Entwicklung von riesigen, monolithischen Softwaresystemen begünstigt, mit all den damit verbundenen Vor- und Nachteilen. Das sollte und darf man aber nicht pauschal schlechtreden. Im Hinblick auf die Datenmodelle gibt es Fälle, bei denen sehr viel Know-how in das Design der Datenbank investiert wurde und man eine modulare und fachlich gut strukturierte monolithische Datenbank vorfindet. In so einem Idealfall findet man oft auch Modulithen auf der Applikationsseite, und die Systeme sind nach wie vor sehr leistungsfähig. Da zuletzt genannte Szenarien aber doch selten sind, kann der alltägliche Spruch "Never change a running system" hier seine beruhigende Wirkung nicht ausspielen.

Bei Banken, Versicherungen und in vielen Bereichen des öffentlichen Dienstes spielen Transaktionalität und die Integrität der Datenbankinhalte eine entscheidende Rolle. Beides ist mit relationalen Datenbanken sehr leicht zu erreichen, und wenn die Daten an einem Ort sind, ist es oft auch leichter, deren Konsistenz zu gewährleisten. Allerdings hat diese Vorgehensweise auch ihren Preis: Die Datenbestände wurden immer größer und die Struktur der Datenbanken immer komplexer. Viele dieser Datenbanken haben mittlerweile das Problem, die Interessen der Konsumenten der Daten mit den Ansprüchen der Produzenten in Einklang zu bringen. Müssen große Datenmengen in kurzer Zeit gespeichert werden, geht dies oft zulasten kurzer Zugriffszeiten in der lesenden Verarbeitung und umgekehrt.

Allerdings gibt es auch einige Kritikpunkte an diesem Architekturpattern.

In unserer täglichen Arbeit sehen wir oft große, relationale Datenbanksysteme, in denen die fachliche Trennung der Inhalte schlecht umgesetzt wurde. Dies führt in der Datenbank zu einer starken Kopplung der Daten, und macht den Zugriff aus der Applikation (oder den Applikationen) heraus sehr aufwendig und fehleranfällig. Sind Änderungen am Datenmodell erforderlich, kann man die Auswirkungen auf die Konsumenten sehr schlecht einschätzen, und es kann sehr viele Kompromisse erfordern, bis alle Nutzer der Datenbank wieder fehlerfrei arbeiten.

Ein zweiter Aspekt, der uns immer wieder begegnet, ist, dass oft sogar Geschäftslogik in die Datenbank verlagert wurde - Stichwort: Stored Procedures. Ja, diese Lösung ist sehr elegant, und wenn man Daten an ihrem Ursprungsort auswerten und modifizieren kann, bringt das oft große Performancegewinne. Der Preis ist allerdings sehr hoch: Fehler muss man an mehreren Stellen suchen, Anpassungen der Programmlogik in der Datenbank und in den angeschlossenen Anwendungen müssen zusammenpassen, und oft sind es auch unterschiedliche Teams, die auf die jeweilige Programmierung spezialisiert sind. Das Schlimmste allerdings ist, dass die Geschäftslogik nicht mehr an einer Stelle zu finden ist, was fachliche Modifikationen an diesen Systemen zu einem großen Risiko macht.

Ein dritter und für uns entscheidender Aspekt ist, dass die großen, traditionellen relationalen Datenbanken nicht wirklich cloudfähig sind. Klar kann man DB2 oder Oracle in einen Container stecken, das geht aber nur mit "kleinen" Datenbanken, und die Stärken dieser Systeme sind in dieser Welt nicht verfügbar und passen nicht zum Cloud-Native-Paradigma.

Viel schlimmer ist schließlich noch, dass ein zentrales Datenbanksystem einen Single Point of Failure darstellt. Das gilt nicht nur für den Worst-Case, dass die Datenbank komplett ausfällt oder nicht erreichbar ist, sondern auch für die Skalierbarkeit. Optimierungen von lesenden Zugriffen stehen generell in Konkurrenz zu den schreibenden, und damit gibt es immer Gewinner und Verlierer bei den Anwendungen, die eine gemeinsame Datenbank verwenden. Ist die Anwendungslandschaft heterogener, so kämpft man ganz schnell mit DB-Locks und Racing-Conditions, die oft sehr schwer zu finden und zu beheben sind. So etwas möchte man in modernen, servicebasierten Architekturen nicht mehr haben.

Was können wir also tun, um von der Datenbank als Zentrum der Datenverarbeitung wegzukommen, ohne auf die genannten Vorteile verzichten zu müssen?

Lösungsstrategie

Die Vorteile von servicebasierten Architekturen liegen auf der Hand. Die Geschäftslogik ist in fachliche Domänen untergliedert, in denen sogenannte Bounded Contexts einen Serviceschnitt definieren. Zugegeben, die Vorarbeit, zu einer solchen Struktur zu kommen, ist selten trivial. Aber der Aufwand lohnt sich, erlangt man doch Autonomie in den fachlichen Domänen und kann diese - in der Regel kleinen - Datenbestände viel besser strukturieren und verarbeiten. Ein weiterer Vorteil ist die Wahl eines geeigneten Datenbanksystems. Es ist nicht zwingend notwendig, für jede Domäne die gleiche Datenbanktechnologie zu verwenden. In vielen Fällen sind NoSQL-Lösungen eine gute Wahl und bringen signifikante Verbesserungen für die Datenmodellierung und für die Verarbeitungsgeschwindigkeit. Natürlich stehen auch hier relationale Datenbanken zur Verfügung, diese können aber viel kleiner ausgelegt werden, und man spart durch die Vielzahl an Anbietern unter Umständen einiges an Lizenzkosten.

Dadurch, dass jetzt die Geschäftsdaten auf die Domänen und Unterdomänen verteilt sind, sinkt das Risiko, dass bei einem Ausfall der Datenbank nichts mehr geht. Die fachliche Integrität der einzelnen Datendomänen lässt sich viel leichter gewährleisten, und wenn man das Konzept der Datenprodukte beherzigt, können wertvolle und leistungsfähige Schnittstellen die Verarbeitung und den Austausch der Daten zwischen den Domänen erleichtern und absichern. Die Autonomie in der Datenhaltung hat für mich den gleichen Stellenwert wie die Autonomie der Entwicklungsteams in den Domänen.

Servicebasierte Architektur

Man darf allerdings nicht glauben, dass der Schritt zu einer servicebasierten Architektur mit verteilter Datenhaltung ein einfacher ist. Die Aufteilung der Datensouveränität geht mit einer wachsenden Komplexität einher. In einer monolithischen Welt mit einer zentralen Datenbank wurden viele Abkürzungen genommen, und der Big Ball of Mud (Modules) ging oft mit einem Big Ball of Data einher. Viele Unternehmen scheitern gerade daran, ihre Daten zu strukturieren, weil sie die Komplexität schlicht nicht mehr verstehen und damit die Angst besteht, Daten oder besser Datenbeziehungen zu verlieren und darunter die Geschäftsprozesse leiden.

Aus unserer Erfahrung kann man nur eindringlich dazu raten, die Methoden des Domain-Driven Designs zu nutzen! Man muss nicht gleich die ganze Welt retten und die ganze Datenbank- und Applikationslandschaft in einem Schritt modernisieren. Nehmen Sie sich etwas Zeit und identifizieren Sie Ihre Kerndomänen, erschließen Sie diese mittels Event Storming oder Domain Story Telling. Wenn Sie dies getan haben, ist der erste Schritt für eine Extraktion der relevanten Domänendaten erfolgt, und man kann sich die geeignete Datenbanktechnologie aussuchen und die Schnittstellen für den Datenaustausch mit anderen Diensten und Domänen überlegen. Das geht immer, sowohl bei dialogorientierten Anwendungen als auch bei der Stapelverarbeitung.

Es gibt aber noch einen weiteren Vorteil, wenn man diesen Weg geht. Data Science und Künstliche Intelligenz werden für die Unternehmen immer wichtiger und damit auch die Auswertung der Geschäftsdaten. Hat man seine Geschäftsdaten in Domänen unterteilt und diese ordentlich modelliert, so kann man dieses Wissen nutzen, um ein Data Warehouse oder einen Data Lake mit konsistenten, strukturierten und vor allem gut verstandenen und vertrauenswürdigen Daten zu bestücken. In diesem Zusammenhang zeichnen sich Datenprodukte dadurch aus, dass sie kuratierte Metadaten enthalten, die man für Data-Science-Algorithmen und Modelle der Künstlichen Intelligenz viel besser verwenden kann.

Zusammenfassung

Datenbankzentrierte Architekturen haben so langsam ihre Daseinsberechtigung verloren. Alle Daten liegen in einer riesigen, oft schlecht strukturierten und dokumentierten relationalen Datenbank, die als zentraler Synchronisationspunkt dient. Sie ist historisch gewachsen und wird oft auch als Data-Warehouse genutzt. Dieses Architekturpattern birgt viele Risiken und bei einem Ausfall der Datenbank ist oft die gesamte Anwendungslandschaft betroffen.

Es führt daher kein Weg daran vorbei, sich von diesem Datengrab zu trennen und sich die Mühe zu machen, seine Daten besser zu verstehen und flexibler zu nutzen. Das ist gar nicht so schwer, denn mit Domain Driven Design (DDD) steht einem eine flexible und bewährte Methode zu Verfügung. Mit DDD ist es möglich, schrittweise und mit überschaubarem Risiko seine Geschäftsdaten auf Domänen zu verteilen, sie besser zu verstehen und in Form von Datenprodukten universell nutzbar zu machen. Moderne Softwarearchitekturen können genutzt werden und wohl definierte Serviceschnittstellen lösen den Wildwuchs bei komplexen Datenbankzugriffen ab.

Fazit: Die Datenhoheit gehört in die Domänen und deren Services und nicht in eine globale Datenbankinstanz.