Lesezeit: 10 Minuten

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.

Blogautor

Peter Diefenthäler
Senior Softwarearchitekt ARS Computer und Consulting GmbH
Ihr Erfolg ist unser Ziel

Stehen Sie vor komplexen IT-Projekten? Mit unserer Expertise bieten wir Ihnen maßgeschneiderte Lösungen. Erfahren Sie mehr.

Werde Teil unseres Teams

Wir suchen ständig nach neuen Talenten. Für dich haben wir genau die richtige Stelle. Schau dir unsere offenen Positionen an.

Noch Fragen? Wir helfen Ihnen gerne!

Headerbild zu Datenbank Consulting
Service

Individuelle & professionelle Beratung für Ihre Datenbanken

Flexible, sichere und schnell arbeitende Datenbanksysteme bilden als zentraler Bestandteil der Unternehmenssoftware die stabile Grundlage Ihrer täglichen Arbeit. Profitieren Sie jetzt von unserer ganzheitlichen Datenbank-Beratung!

Blog 16.03.23

Wie die MACH-Architektur und API-First helfen können

Heute habe ich Sven Baumgart, Gründer und CEO von Tremaze, zu Gast. Gemeinsam mit Sven tauchen wir in die Welt der App-Entwicklung ein. Tremaze hat zwei Anwendungen, Tremaze und Tagea, entwickelt. In der neuen insights!-Folge verrät Sven, wie sie bei der App-Entwicklung mit nur vier Vollzeitentwicklern vorgehen und wie die MACH-Architektur und der API-First Ansatz helfen können, kostengünstig Apps zu aufzubauen. Außerdem geht Sven auf ihre Herausforderungen und Best Practises ein.

Optimierungslösungen
Kompetenz 25.02.25

Optimierungslösungen

Viele Geschäftsprobleme und Herausforderungen lassen sich nicht mehr durch Regelwerke und Entscheidungstabellen abbilden. Komplexe Geschäftsprobleme dieser Art können dann allenfalls noch mit Ansätzen der mathematischen Optimierung gelöst oder verbessert werden.

Blog

Krisenbewältigung & Aufbau einer nachhaltigen Zukunft mit KI

Non-Profit-Organisationen entwickeln KI-Modelle, um globale Herausforderungen zu bewältigen - und ziehen daraus Lehren für Unternehmen weltweit

Kompetenz 25.02.25

Graphentechnologie

Wir helfen Ihnen, das volle Potential der Graphen zu nutzen, um Ihr Unternehmen zu transformieren. Unser Fachwissen reicht von der Modellierung von Graphdatenbanken und Graph Data Science bis hin zu generativer KI.

Headerbild zu Datenbanken mit Open Source
Technologie 25.02.25

Datenbanken mit Open Source

Jede dynamische Applikation braucht eine Form von Datenbank, um ihre Daten logisch und sortiert speichern zu können. Jedoch gibt es nicht eine One-size-fits-all Lösung, sondern es sollte immer auf den Anwendungsfall geschaut werden, um die passende Wahl zu treffen.

Wissen 23.07.24

Graphdatenbanken in der Supply Chain

Die Lieferkette ist ein komplexes Netzwerk von Lieferanten, Herstellern, Händlern und Logistikdienstleistern, das den reibungslosen Fluss von Waren und Informationen sicherstellen soll. Dabei steht die moderne Supply Chain vor zahlreichen Herausforderungen.

Broker Architektur
Technologie 25.02.25

Broker Architektur

Mit einem Message Broker transformieren Sie Nachrichtenformate in ein oder mehrere Formate, priorisieren die Nachrichtenübermittlung, verbinden heterogene Systemen & vieles mehr.

Technologie Übersicht

Wir sind Ihr Partner rund um Snowflake

Mit der Snowflake Data Cloud verwalten Sie Ihre Daten zentral an einem Ort. Wir unterstützen und beraten Sie gerne zu Snowflake.

Blog 27.02.25

Cloud-Native Architektur

Cloud Technologien haben auch in der Welt der Anwendungsentwicklung Änderungen mit sich gebracht - aber was steckt hinter dem Begriff "Cloud-Native"?

Kompetenz 25.02.25

Cloud-native Architektur

Digitale Services erfordern einen hohen Reifegrad in der Architekturarbeit! Service-Qualität, Verfügbarkeit, Stabilität und Vernetzung mit angrenzenden Ökosystemen sind die Spitze des Eisbergs, der von Ihren Kunden in der Verwendung Ihrer Services maßgeblich wahrgenommen wird.

Blog 17.11.22

Workation - ein Arbeitsmodell mit Zukunft?

In der zweiten insights!-Folge der zweiten Staffel mit der Unternehmerin, Autorin und Keynote Speakerin Ruth Cremer! Joubin Rahimi steht dieses Mal dessen Marketingexpertin Anna-Lena Lüderitz zur Seite. Zu dritt tauschen sie Gedanken zum möglichen Arbeitsmodell der Zukunft aus, der sogenannten ,,Workation''. Ist die Idee, Arbeit und Urlaub miteinander zu verschmelzen umsetzbar, ohne dass Unternehmen dabei den Kürzeren ziehen? Und wenn ja, was gilt es bei der Implementierung von Workation zu beachten?

Kompetenz 25.02.25

Mit Technologie die Zukunft gestalten

ARS Computer und Consulting ist eines der führenden Unternehmen im Bereich Software Engineering. Unsere Mission: The Art of Software Engineering. Dies beinhaltet hochwertige Beratung und erfolgreiche Projekte zur agilen Entwicklung qualitativ exzellenter Software.

Service

Graphentechnologie: Holen Sie mehr aus Ihren Daten heraus

Graphentechnologie hilft Unternehmen, Daten und Informationen besser zu verstehen und zu nutzen. Sie basiert auf der Darstellung von Daten als Knoten (Entitäten) und Kanten (Beziehungen). Diese Struktur ermöglicht es, die Verbindungen zwischen Datenpunkten zu modellieren und tiefere Einblicke zu gewinnen, die in traditionellen relationalen Datensammlungen oft verborgen bleiben.

Logo Oracle
Technologie Übersicht

Beratung rund um Oracle

Oracle gehört zu den weltweit führenden Anbietern von Soft- und Hardwareprodukten.

Headerbild zu IBM DB2
Technologie

IBM Db2

Die Datenbank IBM Db2 ist neben dem klassischen Einsatz im operativen Bereich seit vielen Jahren auch als führende Data Warehouse Datenbank im Markt etabliert.

Microservices, serviceorientierte Architektur & BPM
Kompetenz 25.02.25

Microservices, Serviceorientierte Architektur & BPM

In der serviceorientierten Architektur werden IT-Komponenten zu einem gemeinsamen Service-Netz zusammengefasst. Einzelne Anwendungen treten hinter den Schnittstellen zurück und ermöglichen eine Zusammenarbeit der Dienste.

Logo Concordia Versicherungen
Referenz

Digitaler Arbeitsplatz bei Concordia

Einrichtung eines digitalen Arbeitsplatzes, der alle Anforderungen moderner Zusammenarbeit berücksichtigt und die technologischen Möglichkeiten ausschöpft

Referenz 31.08.23

EgeTrans – Die Zukunft von individueller Logistiksoftware

Erfahren Sie, wie EgeTrans die Zukunft der Individualsoftware auf der IBM i (AS/400) gestaltet und damit die Logistikbranche neu definiert. Ein Blick in eine innovative Welt, wo Technologie und Fortschritt sich treffen!

Blog 02.05.24

KI & Personalisierung: Zukunft der Softwareentwicklung

In dieser Folge von insights! erläutert Ralf Trapp, CEO von procelo, die Bedeutung von Menschen in der Softwareentwicklung. Dabei teilt er seine Erfahrungen und Erkenntnisse aus seiner langjährigen Tätigkeit im Mittelstandsbereich und gibt wertvolle Einblicke, wie Unternehmen ihre Softwareentwicklungspraktiken optimieren können, um hochwertige und zuverlässige Produkte zu liefern.

Bleiben Sie mit dem TIMETOACT GROUP Newsletter auf dem Laufenden!