Zum Inhalt springen
Alexander von Boguszewski
Alexander von Boguszewski
  • Startseite
  • Referenzarchitekturen & Datenmodelle
  • Impressum

Beitragsformat: Kurzmitteilung

article
AvB Alexander von Boguszewski
· 10. August 2026 · 7 Minuten zu lesen

Fast jedes Unternehmen sammelt heute Daten (das neue Öl für die ältern unter uns). Und fast jedes behandelt sie anschließend wie Müll. Nach meiner Erfahrung nach liegt ein Großteil aller Unternehmensdaten ungenutzt in Systemen – gespeichert, bezahlt, gesichert und nie wieder benutzt. Das ist der eigentliche Skandal hinter dem Modewort „datengetrieben“: Nicht der Mangel an Daten, sondern die systematische Weigerung, mit ihnen etwas zu tun. 

Value Chain - Data to Insights
Data to Insights (Value Chain)

Die Data Value Chain ist ein Werkzeug, das genau diese Lücke sichtbar machen soll. Dazu muss man sie jedoch gegen den Strich lesen. Die gängige Darstellung verführt nämlich zu einem teuren Denkfehler: Sie wird von links nach rechts gelesen, von der Datenerfassung bis zur Nutzung. Genau in dieser Reihenfolge investieren Unternehmen meist. Sie stecken Geld und Aufmerksamkeit in die linke Hälfte – Sammeln, Speichern und Aufbereiten – und hoffen, dass rechts irgendwann ein Wert entsteht. Das ist der Grund, warum so viele Datenprojekte scheitern. Meine These lautet daher: Eine von links aufgebaute Data Value Chain produziert vor allem volle Festplatten. 

Das Konzept der Wertschöpfungskette wurde ursprünglich 1985 von Porter entwickelt, um zu zeigen, wie ein Unternehmen aus Rohstoffen über Produktion, Vertrieb und Service Schritt für Schritt Wert aufbaut. Der entscheidende Gedanke war dabei nie die Kette selbst, sondern die Frage: Welcher Schritt fügt tatsächlich Wert hinzu und welcher verbrennt nur Ressourcen? Für das Data Management ist es ein pragmatisches Konstrukt und Werkzeug, um Engpässe zu identifizieren. Genau hier liegt der Wert des Modells – und zugleich seine Gefahr. Als Analysewerkzeug ist es hervorragend geeignet. Als Poster im Data-Office oder in PPTX ist es hingegen nutzlos. 

 Der technische, kontrollierbare, Teil (Identify, Acquire, Store, Prepare, Cleanse, Release) ist verhältnismäßig einfach. Man kann ihn ausschreiben, an Dienstleister vergeben, in Ticketsystemen abbilden und mit Fortschrittsbalken versehen. 

Wie die Daten genutzt werden und welchen Einfluss sie auf Entscheidungen haben, ist eine ganz andere Sache. Hierbei geht es nicht mehr um Technik, sondern um Menschen, Gewohnheiten und Macht. „Encourage data use for decisions“ und „Build habits of data use“ sind keine IT-Aufgaben. Es sind Verhaltensänderungen. Und Verhaltensänderungen lassen sich nicht einfach umsetzen. 

Genau deshalb scheitert es in der Praxis fast immer an derselben Stelle: nach der Veröffentlichung. Das bloße Sammeln und Bereitstellen von Daten erzeugt keinen Wert. Es entstehen Kosten. Laut Gartner belaufen sich die Folgen schlechter Datenqualität auf durchschnittlich 12,9 Millionen Dollar pro Jahr und Unternehmen (https://www.gartner.com/en/data-analytics/topics/data-quality). Das ist Geld, das zum Teil für Daten ausgegeben wird, die niemand nutzt oder denen niemand traut. 

„Daten sind das neue Öl“ – eine Metapher, die in die Irre führt 

Die Erzählung, mit der Datenstrategien seit Ewigkeiten verkauft werden, lautet: Daten seien das neue Öl. Sie klingt gut, ist aber trotzdem falsch. Wer dieser Meinung ist, glaubt, dass der Wert von Daten in der geförderten Menge steckt. Also fördert er mehr. Er baut Data Lakes, kauft Speicher und richtet Pipelines ein.  

  

Meiner Meinung nach wurde die Datenrevolution jedoch nicht durch das Volumen der Daten ausgelöst, sondern durch die Erkenntnis, dass Daten wertvolle Verwendungen haben. Öl hat Wert, sobald es aus dem Boden kommt. Daten hingegen haben erst dann einen Wert, wenn jemand auf ihrer Grundlage anders handelt als vorher. Ein Datensatz, der keine Entscheidung verändert, ist ökonomisch wertlos – egal, wie sauber, wie vollständig oder wie schön er visualisiert ist. Genau das verfehlt die linkslastige Denkweise: Wert entsteht ausschließlich am rechten Ende der Kette, im Schritt „Change“. 

Warum Silos kein Technikproblem sind 

Der meistgenannte Grund für ungenutzte Daten sind Silos, also abgeschottete Datenbestände, die nicht miteinander „sprechen”. Die übliche Reaktion darauf ist ein Technikprojekt: eine zentrale Plattform, ein Data Warehouse oder ein „Single Point of Truth“.  

Das behandelt jedoch nur das Symptom. Silos entstehen jedoch selten, weil die Technik es erzwingt. Sie entstehen, weil Abteilungen ihre Daten als Besitz begreifen und das Teilen als Kontrollverlust erleben. Selbst wenn man die schönste Plattform baut, wird der Vertrieb seine Daten weiter zurückhalten, in schlechter Qualität (Aggregate, Teilmengen) einspeisen oder ein eigenes System nutzen, wenn er weiterhin fürchtet, dass offengelegte Zahlen seine Schwächen zeigen. Der teuerste Flaschenhals sitzt fast nie in der Datenbank. Er liegt in den Anreizen der Menschen, die die Daten produzieren und nutzen sollen. Daher wird selbst die beste Datenproduktstrategie ohne eine Verhaltensänderung nur wenig Wirkung zeigen. 

Es gibt ein starkes Gegenargument, das man nicht kleinreden sollte: Ohne eine solide linke Hälfte (die Technik) gibt es keine rechte (den Nutzen). Wer schlechte, unvollständige oder nicht vertrauenswürdige Daten produziert, darf sich nicht wundern, wenn niemand danach handelt. Vertrauen entsteht durch Transparenz und Nachvollziehbarkeit – beides muss bereits beim Sammeln und Aufbereiten der Daten gewährleistet sein. Datenqualität ist kein Luxus schlechte Daten kosten Millionen und lassen inzwischen sogar KI-Projekte scheitern, nur sieht man diese Kosten nicht. Sie entstehen durch Doppelarbeit und falsche Entscheidungen. 

Der Einwand ist daher zwar richtig, trifft die These aber trotzdem nicht. Denn es geht nicht um die Reihenfolge des Bauens, sondern um die Reihenfolge des Denkens. Die Kette muss weiterhin von links nach rechts durchlaufen werden. Aber man muss sie von rechts nach links planen. Die erste Frage lautet nicht „Welche Daten haben wir?“, sondern „Welche Entscheidung soll geändert werden und welche Informationen bräuchte es dafür?“ Von dieser Antwort aus arbeitet man rückwärts: Welche Analyse, welche Aufbereitung, welche Datenquelle? Alles, was auf diesem Rückweg nicht benötigt wird, muss nicht gesammelt werden. 

Der erste Schritt heißt daher nicht „Daten sammeln“, sondern „Consult with stakeholders & determine levels of granularity“. Der Bedarf steht am Anfang, nicht die Quelle. Die meisten Umsetzungen ignorieren diesen ersten Schritt und beginnen de facto bei „Acquire Data“. Damit ist die ist der Kern für ein Scheitern eines Datenprojekts schon gelegt, bevor die erste Zeile geschrieben ist. 

Was das für die Umsetzung heißt 

Eine Data Value Chain zu implementieren bedeutet daher zunächst einmal, für jedes geplante Datenprodukt eine konkrete Entscheidung zu benennen, die es verändern soll, sowie eine Person, die diese Entscheidung trifft. Gibt es diese Person nicht oder kann sie keine Auskunft darüber geben, was sie anders tun würde, wird das Produkt nicht gebaut. Kein Dashboard ohne Adressaten. Kein Datensatz ohne Verwendung. Das klingt hart, aber nur so kann man später einen Nutzen bestimmen. 

Der zweite Schritt besteht darin, die Nutzung statt der Produktion zu messen. Die meisten Datenteams berichten, wie viele Datenquellen sie angebunden haben, wie viele Reports sie erstellt haben oder wie oft ein Report aufgerufen wurde. Das ist die Fördermenge, nicht der Nutzen. Interessant ist die einzige Zahl, die zählt: Wie viele Entscheidungen wurden anders getroffen, weil die Daten vorhanden waren? Diese Zahl ist unbequem, weil sie oft klein ist und sich nur schwer ermitteln lässt. Genau deshalb wird sie selten erhoben. 

Im dritten Schritt sollte die einfachste Lösung bevorzugt werden, die den Zweck erfüllt. Nicht jede Frage braucht eine Plattform – was die meisten Hersteller sicherlich verneinen würden. Manche benötigen eine saubere Tabelle und eine Person, die sie erläutert. Komplexe Probleme dürfen komplexe Antworten verlangen, doch Komplexität hat ihren Preis. Wenn eine schlichte Regel dasselbe leistet wie ein Governance-Apparat, sollte die Regel den Vorzug erhalten. 

Die eigentliche Frage 

Bevor also die nächste Plattform beschafft und der nächste Data Lake befüllt wird, lohnt sich die folgende Frage: Wenn Ihr Unternehmen morgen aufhören würde, neue Daten zu sammeln, und stattdessen nur die vorhandenen wirklich nutzen würde – würde irgendjemand den Unterschied überhaupt bemerken? Wer diese Frage ehrlich beantwortet, braucht die halbe Strategie nicht mehr. 

Quellen 

Hinterlasse einen Kommentar
article
AvB Alexander von Boguszewski
· 27. Oktober 2025 · 2 Minuten zu lesen

Beratung ist kein Selbstzweck. Kein PowerPoint-Marathon. Kein Buzzword-Bingo. Beratung muss Wert schaffen. Doch was bedeutet „Value“ im Consulting wirklich? Und wie gelingt es, diesen systematisch zu definieren, zu kommunizieren und zu realisieren?

Wichtig sind folgende Themen:
✅ Versteh die Welt deines Kunden – wirklich, nicht oberflächlich.
✅ Starte jede Beratung mit einer Discovery – finde die echten Probleme.
✅ Stell die unbequemen Fragen – zu Zielen, Wahrnehmung, Prioritäten.
✅ Quantifiziere den Nutzen – mit belastbaren Value Cases.

Der erste Schritt: Verstehen, was den Kunden wirklich bewegt. Seine Mission, seine Prioritäten, seine Position im Markt, seine KPIs. Ohne dieses Verständnis ist jede Lösung nur geraten.

Discovery ist Pflicht. Wer ohne Discovery startet, löst Symptome statt Ursachen. Du musst die echten Herausforderungen und Ambitionen des Kunden erkennen – nicht nur das, was im Kick-off gesagt wurde. Stell auch die unbequemen Fragen. Was sind kurzfristige und langfristige Prioritäten? Was passiert, wenn wir dieses Projekt nicht machen? Wer profitiert persönlich von diesem Projekt – und wer verliert? Welche KPIs würden beweisen, dass wir gescheitert sind? Was wurde in der Vergangenheit versucht – und warum hat es nicht funktioniert?

Versuche herauszufinden wie der Kunde den Nutzen definiert und ist das deckungsgleich mit deiner Sicht?

Value/Nutzen muss quantifiziert und kommuniziert werden. Die C-Suite spricht in Zahlen. Kenne Umsatz, EBIT, Wachstumsziele. Entwickle Hypothesen, validiere sie und baue einen belastbaren Value Case. Und – Nutzen ist mehr als Geld. Neben Finanzielle Dimensionen wie Umsatzsteigerung, Kostenreduktion, Kapitaleffizienz und Cashflow-Optimierung, gibt es auch Nicht-finanzielle Dimensionen:

  • Kundenbindung (z. B. Net Promoter Score)
  • Nachhaltigkeit (z. B. CO₂-Reduktion)
  • Talentbindung und -gewinnung
  • Innovationskraft (z. B. Time-to-Market)
  • Markenwert und Reputation
  • Resilienz (z. B. Krisenfestigkeit)
  • Compliance
  • Kultureller Wandel (z. B. Leadership, Diversity)

Consulting Value ist kein Buzzword – sondern ein strategisches Prinzip. Wer echten Wert schaffen will, muss wirklich verstehen was die Kunden umtreibt, klar kommunizieren und konsequent quantifizieren. So wird Beratung zum echten Wachstumstreiber – für Kunden und für das eigene Unternehmen.

note
AvB Alexander von Boguszewski
· 21. Oktober 2025 · 2 Minuten zu lesen

Die Gefahren einer Cloud-Monokultur sind grade offensichtlich geworden.

Gestern hat Amazon gezeigt, wie fragil unsere digitale Welt ist. Ein technischer Fehler in ihrer Infrastruktur, und plötzlich fallen Signal, Fortnite, Snapchat, aber auch Behörden-Systeme aus. Nicht, weil diese Dienste schlecht gebaut wären – sondern weil sie sich freiwillig in die Abhängigkeit eines der drei Hyperscaler begeben haben. Das ist kein IT-Problem. Das ist ein strategisches Versagen. Es zeigt aber vor allem die Bedeutung einer sauberen globalen Infrastrukturarchitektur.
Digitale Souveränität ist kein Buzzword. Sie ist überlebenswichtig. Wenn ein einziger Cloud-Anbieter zum Single Point of Failure für ganze Branchen wird, sind wir systematisch verwundbar. Es geht nicht um „mehr Uptime“, sondern um Architektur, die uns resilient macht: Datenhoheit, entkoppelte Systeme, echte Multi-Cloud-Optionen. All das diskutiere ich seit Jahren wenn ich mit meinen Klienten über Architekturoptionen spreche – doch es wird kaum umgesetzt.
Solange wir uns weiter in die Arme von Amazon, Google & Co. werfen, bleiben wir Geiseln ihrer Infrastruktur. Wir brauchen dringend mehr Investitionen in offene Standards, gemeinsame (europäische) Multi-Cloud-Plattformen sowie politische Rahmenbedingungen, die technologische Eigenständigkeit fördern. Bemühungen diese Souveränität „künstlich“ herzustellen sind zum Scheitern verurteilt, wir brauchen resiliente, und vor allem wettbewerbsfähige Ökosysteme die als echte Architektur Option wahrgenommen werden. Oder warten wir einfach auf den nächsten GAU?

article
AvB Alexander von Boguszewski
· 7. Oktober 2025 · 2 Minuten zu lesen

Daten sind allgegenwärtig. Zahlen, Wörter, Bilder, Videos. Aber mal ehrlich: Daten allein haben erst einmal keinen Wert. Was soll schon eine Zahl wie „18“? Ohne Kontext ist das nichts. Alter? Temperatur? Hausnummer? Kredit-Score? Wir wissen es nicht. Aber so sind nun einmal Rohdaten. Und genau hier liegt das Problem: Viele glauben, dass das Sammeln von Daten bereits der große Wurf ist. Falsch!

Denn Daten benötigen einen Kontext. Erst dann werden sie zu Informationen. Wir werfen die Begriffe „Daten” und „Information” oft durcheinander, aber der Unterschied ist entscheidend: Daten sind Fakten. Informationen haben Bedeutung. Ohne Bedeutung gibt es keine Entscheidungen und keinen Wert.
Damit sind wir beim Kern der Sache: Was bringt uns das alles? Wenn wir Daten horten, ohne sie in Erkenntnisse zu verwandeln, verbrennen wir Geld.

Der Idee der DIKW-Pyramide aus den 1950er-Jahren zufolge (Data → Information → Knowledge → Wisdom) ist der Weg klar: Daten sind die Basis, aber das Ziel ist Wissen – und idealerweise kluge Entscheidungen.
Warum ist das wichtig? Viele bleiben in den unteren Leveln stecken. Die sammeln Daten, vielleicht schaffen sie es zu Informationen, aber Wissen extrahieren? Leider nicht. Genau da entsteht Nutzen, bzw. Business Value – und das ist der Grund, warum wir uns mit Daten beschäftigen sollten.

Daten sind also kein Selbstzweck. Sie müssen etwas bewirken. Hier kommt jedoch die unbequeme Wahrheit: Business Value ist schwer messbar. Warum? Weil er oft indirekt entsteht. Effizienzgewinne, bessere Entscheidungen oder neue Produkte zeigen sich nicht sofort in der Bilanz. Und manchmal ist der Wert nicht monetär, sondern strategisch, zum Beispiel in Form von besserer Kundenzufriedenheit oder geringeren Risiken. Das macht die Messung komplex. Um das greifbarer zu machen, nutzen wir eine einfache Definition:

  • Billiger: Kosten senken. Effizienzen in Prozessen, Supply Chains oder Einkauf identifizieren. Weniger Zeit, weniger Geld. (Beispiel: Analyse von Produktionsdaten zur Reduktion von Ausschuss spart Millionen.)
  • Besser: Produkte und Services verbessern. Qualität steigern, neue Angebote entwickeln. (Beispiel: Kundendaten zeigen, welche Features wirklich genutzt werden – und welche nicht.)
  • Smarter: Klügere Entscheidungen treffen. Kunden besser verstehen, Risiken minimieren, Chancen erkennen. (Beispiel: Predictive Analytics im Vertrieb erhöht Abschlussquoten und reduziert Churn.)

Diese drei Ziele sollten nicht nur Schlagworte sein – sie sollten der Maßstab sein, an dem sich jedes „Datenprojekt“ messen lassen muss. Daten sind der Anfang, nicht das Ende. Der Weg führt von Daten zu Information, zu Wissen, zu Wert.

note
AvB Alexander von Boguszewski
· 2. April 2025 · 2 Minuten zu lesen

Bei einem Zero-ETL-Ansatz, also einem einfachen Ingest, werden die Daten direkt und ohne aufwändige Aufbereitung aus einer Datenquelle in einen Data Lake eingespeist. Die Rohdaten stehen dann in ihrem ursprünglichen Format für die Analyse und Verarbeitung zur Verfügung. Durch den Verzicht auf eine Pipeline soll die Datenverarbeitung beschleunigt und die Datenintegration vereinfacht werden.

Soweit die Theorie. Warum halte ich dieses Integrationsmuster trotz seiner scheinbaren Vorteile für problematisch?

Wir haben schon seit Jahrzehnten Erfahrung mit Punkt-zu-Punkt-Integration und das Ergebnis mutiert immer wieder zu einer Spaghetti-Architektur. Egal, ob’s um einen neuen Anwendungsfall, eine neue Analyse oder eine neue Verbindung geht: Die Komplexität steigt immer schneller, und am Ende ist das Ganze ein unübersichtliches Netz von Abhängigkeiten. Das macht es äußerst schwierig, Änderungen vorzunehmen oder neue Funktionen hinzuzufügen, ohne dass etwas schief geht. Zusammen mit schlechten Entwurfspraktiken, mangelnder Dokumentation und einer Ansammlung technischer Schulden im Laufe der Zeit führt diese zunehmende Komplexität zu erheblichen Wartungsproblemen, erschwert die Skalierbarkeit und erhöht das Risiko von Softwarefehlern und Systemausfällen. Zero ETL kann zwar kurzfristig Vorteile bieten, aber langfristig scheitert es oft an diesen Herausforderungen.

Eine gute Integrationsarchitektur ist wichtig, weil sie die Anzahl der Abhängigkeiten reduziert. Das heißt, Änderungen und Updates lassen sich leichter durchführen, ohne dass unbeabsichtigte Nebeneffekte auftreten. Außerdem ist es einfacher, neue Anforderungen zu erfüllen oder neue Mitarbeiter einzuweisen. Und wenn die Software weniger komplex ist, ist das Risiko von Fehlern, Systemausfällen und Sicherheitslücken geringer. Und wir können langfristig Kosten sparen, weil wir weniger Wartungsaufwand und technische Schulden haben.

article
AvB Alexander von Boguszewski
· 2. Januar 2025 · 1 Minute zu lesen

Über die Feiertage habe ich eine erste Version meiner Data Reference Architecture erstellt, die als Grundlage für moderne, skalierbare und effiziente Datenlösungen dienen kann. Die Architektur beinhaltet wichtige Prinzipien und Komponenten, die in den meisten Datenplattformen eine zentrale Rolle spielen. Die aktuelle Version (0.1) ist erst ein erster Entwurf. Vieles muss noch vereinfacht und konsolidiert werden, um den Anforderungen von großen Unternehmen gerecht zu werden. Ziel ist eine praxisnahe und dennoch flexible Basis, die sich an unterschiedliche Anwendungsbereiche anpassen lässt

Hier zum PDF: DataArchitecture_0_1.

article
AvB Alexander von Boguszewski
· 13. Dezember 2024 · 3 Minuten zu lesen
Beispiel Medallion-Architektur mit Archimate

In meinen letzten Projekten habe ich eine Referenzarchitektur entwickelt, die als Grundlage für den Aufbau von Datenplattformen dient, die sich gut skalieren und anpassen lassen. Ein zentrales Element dieser Architektur ist die Medaillon-Architektur. In meiner Referenzarchitektur kann man die Medallion-Architektur mit den Komponenten „Data Processing“ und „Data Storage Component“ umsetzen. Die einzelnen Schichten (Bronze, Silber, Gold) sind mit Datenobjekten strukturiert.

Beispiel Medallion-Architektur mit Archimate
Medallion-Architektur

Ich möchte uns jetzt mal die Vor- und Nachteile dieses Ansatzes vorstellen:

Weiterlesen →

article
AvB Alexander von Boguszewski
· 20. November 2024 · 2 Minuten zu lesen

In meinen letzten Projekten habe ich gemerkt, dass erfolgreiche Datenarchitekturen auf ähnlichen Capabilities aufbauen. Deshalb habe ich mir eine Capabilities Map erstellt, die die wichtigsten Bereiche für ein effektives und zukunftsfähiges Datenmanagement zeigt. Die Capability Map hilft mir, eine strukturierte Übersicht über die Anforderungen von Projekten an moderne Datenplattformen zu katalogisieren und zu klassifizieren. Ich verwende sie, um Workshops zu strukturieren, Lücken in der Architektur zu identifizieren, den Fokus auf wichtige Themen zu lenken und mit Stakeholdern auf Augenhöhe zu diskutieren.

Weiterlesen →

article
AvB Alexander von Boguszewski
· 19. Juni 2024 · 2 Minuten zu lesen

Datenmodellierung hilft Entwicklern, Datenarchitekten, Business-Analysten und anderen Stakeholdern, die Beziehungen zwischen den Daten zu verstehen. Ein wichtiger Vorteil ist die Verbesserung der Kommunikation zwischen Entwicklern und Fachanwendern. In meinen letzten Projekten kam immer wieder die Frage auf wie detailliert die Modellierung sein soll. Ich denke es muss auf verschiedenen Abstraktionsebenen, je nach Zielgruppe modelliert werden. Der Prozess beginnt mit dem Sammeln von Informationen über die Geschäftsanforderungen von Business Stakeholdern und Endnutzern. Diese Datenobjekte werden dann in Datenstrukturen übersetzt, um einen konkreten Datenbankentwurf zu formulieren. Daher können wir Datenmodelle im Allgemeinen in drei Kategorien einteilen:

Weiterlesen →

article
AvB Alexander von Boguszewski
· 5. April 2024 · 2 Minuten zu lesen

Middleware ist der Klebstoff, der verschiedene Anwendungen in der IT-Landschaft zusammenhält. Da immer mehr Anwendungen in die Cloud verlagert werden, stellt sich die Frage: Brauchen Cloud-native Unternehmen Middleware oder ist sie überflüssig?

Die Versprechungen von Cloud-nativen Anwendungen sind, dass sie wie Legosteine sind, die man nach Belieben zusammensetzen kann. Mit Hilfe von APIs sollen verschiedene Anwendungen nahtlos zusammenarbeiten können. Und eine neue Generation von Cloud-basierter Middleware und IPaaS-Lösungen ermöglicht es, die APIs einfach miteinander zu verknüpfen.
Aber ist der Einsatz komplexer Middleware notwendig, um die Interaktion in der Cloud und zwischen Cloud- und On-Premise-Systemen zu ermöglichen? Oder bedeutet das nur zusätzliche Komplexität?


Ich denke, dass eine geeignete Architektur die Systemlandschaft in ein Portfolio von Komponenten umwandeln kann, die ihre eigenen Integrationsfunktionen bereitstellen (anstatt nur Anwendungen mit fixen APIs). In der Vergangenheit war Unternehmensarchitektur ein Thema für den Elfenbeinturm. Mit Konzepten wie ‚Dumb Pipes, Smart Endpoints‘ ist es jedoch möglich, die IT-Landschaft in Komponenten zu zerlegen, die mit Schnittstellen und Datenmappings ausgestattet sind. Dies ermöglicht es, Änderungen vorab über die Architektur zu bewerten und zu planen, anstatt Anwendungen über die Middleware austauschbar zu halten.
Dies bedeutet, dass die Komponenten Endpunkte mit APIs bereitstellen, wodurch die Middleware in einer Cloud-Umgebung eher als ‚dumme Leitung‘ fungieren kann, die lediglich für die Übertragung von Daten zwischen den Endpunkten verantwortlich ist. Die Verarbeitung und Abbildung der Daten erfolgt in den Endpunkten selbst. Dieses Konzept reduziert die Komplexität der Middleware in einer Cloud-Umgebung und verringert die Abhängigkeit von der verwendeten Middleware-Lösung. Das war natürlich schon immer möglich, dadurch das fast alle Cloud-Anwendungen APIs bereitstellen, ist eine solche Architektur jetzt viel einfacher umzusetz
Weiterlesen →

Beitragsnavigation
This site is powered by WordPress and styled with the Autonomie theme