Datendomänen

Datengitter basieren grundsätzlich auf der Dezentralisierung und der Verteilung der Verantwortung an Domänen. Wenn Sie wirklich einen Teil des Unternehmens verstehen, sind Sie am besten positioniert, um die zugehörigen Daten zu verwalten und ihre Genauigkeit sicherzustellen. Dies ist das Prinzip des domänenorientierten Datenbesitzes.

Um den domänenorientierten Datenbesitz zu fördern, müssen Sie zuerst Ihre Datenarchitektur dekompilieren. Der Gründer von Data Mesh, Zhamak Dehghani, fördert den Domain-Driven Design (DDD)-Ansatz für die Softwareentwicklung als nützliche Methode, um Ihre Datendomänen zu identifizieren.

Die Schwierigkeit bei der Verwendung von DDD für die Datenverwaltung besteht darin, dass der ursprüngliche Anwendungsfall von DDD komplexe Systeme in einem Softwareentwicklungskontext modelliert hat. Es wurde ursprünglich nicht erstellt, um Unternehmensdaten zu modellieren, und für Datenverwaltungspraktiker kann seine Methode abstrakt und technisch sein. Es fehlt oft an Verständnis von DDD. Die Praktiker finden ihre konzeptuellen Vorstellungen zu schwer zu verstehen oder versuchen, Beispiele aus der Softwarearchitektur oder objektorientierten Programmierung auf ihre Datenlandschaft zu übertragen. Dieser Artikel bietet Ihnen pragmatische Anleitung und klaren Wortschatz, damit Sie DDD verstehen und verwenden können.

Domänengesteuertes Design

Das von Eric Evans eingeführte Domain-Driven Design ist eine Methode zur Unterstützung der Softwareentwicklung, die dazu beiträgt, komplexe Systeme für größere Organisationen zu beschreiben. DDD ist beliebt, da sich viele seiner hochrangigen Methoden auf moderne Software- und Anwendungsentwicklungsansätze wie Microservices auswirken.

DDD unterscheidet zwischen gebundenen Kontexten, Domänen und Unterdomänen. Domänen sind Problemplätze, die Sie adressieren möchten. Sie sind Bereiche, in denen Wissen, Verhalten, Gesetze und Aktivitäten zusammenkommen. Sie sehen semantische Kopplung in Domänen, Verhaltensabhängigkeiten zwischen Komponenten oder Diensten. Ein weiterer Aspekt der Domänen ist die Kommunikation. Teammitglieder müssen eine Sprache verwenden, die das gesamte Team teilt, damit jeder effizient arbeiten kann. Diese gemeinsam genutzte Sprache wird als allgegenwärtige Sprache oder Domänensprache bezeichnet.

Domänen werden in Unterdomänen dekompiliert, um die Komplexität besser zu verwalten. Ein gängiges Beispiel hierfür ist das Dekompilieren einer Domäne in Unterdomänen, die jeweils einem bestimmten Geschäftsproblem entsprechen, wie in operationalize data mesh for AI/ML gezeigt.

Nicht alle Unterdomänen sind identisch. Sie können z. B. Domänen als Kern, generisch oder unterstützend klassifizieren. Kerndomänen sind die wichtigsten. Sie sind die geheime Sauce, die Zutaten, die eine Organisation einzigartig machen. Generische Unterdomänen sind nicht spezifisch und in der Regel einfach mit Off-the-Shelf-Produkten zu lösen. Die Unterstützung von Unterdomänen bietet keinen Wettbewerbsvorteil, ist aber erforderlich, um eine Organisation weiter zu betreiben und sind nicht komplex.

Gebundene Kontexte sind logische (Kontext)-Grenzen. Sie konzentrieren sich auf den Lösungsraum: das Design von Systemen und Anwendungen. Es ist ein Bereich, in dem die Ausrichtung des Fokus auf den Lösungsbereich sinnvoll ist. Innerhalb von DDD kann dies Code, Datenbankdesigns usw. umfassen. Zwischen den Domänen und abgegrenzten Kontexten kann es eine Ausrichtung geben, aber es gibt keine strikte Regel, die beide verbindet. Gebundene Kontexte sind technisch und können mehrere Domänen und Unterdomänen umfassen.

Empfehlungen zur Domänenmodellierung

Wenn Sie Datengitter als Konzept für die Datendemokratisierung einführen und das Prinzip der domänenorientierten Datenbesitz zur Erhöhung der Flexibilität implementieren, wie funktioniert dies in der Praxis? Wie könnte ein Übergang von der Unternehmensdatenmodellierung zur domänengesteuerten Designmodellierung aussehen? Welche Lektionen können Sie aus DDD für die Datenverwaltung ziehen?

Machen Sie eine funktionale Geschäftsabgrenzung Ihrer Problemräume

Bevor Sie Ihren Teams gestatten, ihre Daten durchgängig zu verwalten, schauen Sie auf den Umfang und verstehen Sie die Problembereiche, die Sie angehen möchten. Es ist wichtig, diese Übung zuerst durchzuführen, bevor Sie in die Details einer technischen Implementierung springen. Wenn Sie logische Grenzen zwischen diesen Problemräumen festlegen, werden Die Verantwortlichkeiten klarer und können besser verwaltet werden.

Sehen Sie sich Ihre Geschäftsarchitektur an, wenn Sie Ihre Problemräume gruppieren. Innerhalb der Geschäftsarchitektur gibt es Geschäftsfunktionen: Fähigkeiten oder Kapazitäten, die ein Unternehmen besitzt oder austauscht, um einen bestimmten Zweck oder ein bestimmtes Ergebnis zu erreichen. Diese Abstraktion fasst Daten, Prozesse, Organisation und Technologie in einen bestimmten Kontext zusammen mit den strategischen Geschäftszielen und Zielen Ihrer Organisation. Eine Geschäftsfähigkeitskarte zeigt, welche Funktionsbereiche für ihre Mission und Vision notwendig erscheinen.

Sie können die Fähigkeitsaufgliederung eines fiktiven Unternehmens, Tailwind Traders, im folgenden Modell anzeigen.

Tailwind Traders müssen alle funktionalen Bereiche beherrschen, die in der Business Capability Map aufgeführt sind, um erfolgreich zu sein. Tailwind Traders müssen in der Lage sein, Tickets als Teil von Online- oder Offline-Ticket-Management-Systemen zu verkaufen, oder Piloten im Rahmen eines Pilotmanagementprogramms zur Verfügung zu haben. Das Unternehmen kann einige Aktivitäten auslagern und andere als Kern seines Geschäfts halten.

Was Sie in der Praxis beobachten, ist, dass die meisten Ihrer Mitarbeiter um Geschäftsfunktionen herum organisiert sind. Personen, die an denselben Geschäftsfunktionen arbeiten, teilen dasselbe Vokabular. Das gleiche gilt für Ihre Anwendungen und Prozesse, die in der Regel gut ausgerichtet und eng miteinander verbunden sind, basierend auf dem Zusammenhalt der von ihnen unterstützten Aktivitäten.

Die Zuordnung von Geschäftsfunktionen ist ein guter Ausgangspunkt, aber Ihre Geschichte endet hier nicht.

Zuordnen von Geschäftsfunktionen zu Anwendungen und Daten

Um Ihre Unternehmensarchitektur besser zu verwalten, richten Sie Ihre Geschäftsfunktionen, gebundenen Kontexte und Anwendungen aus. Es ist wichtig, einige Grundregeln zu befolgen, wie Sie dies tun.

Die Geschäftsfunktionen müssen auf der Geschäftlichen Ebene bleiben und abstrakt bleiben. Sie stellen dar, was Ihre Organisation tut und auf Ihre Problemplätze ausgerichtet ist. Wenn Sie eine Geschäftsfunktion implementieren, wird eine Realisierung (Funktionsinstanz) für einen bestimmten Kontext erstellt. Mehrere Anwendungen und Komponenten arbeiten innerhalb solcher Grenzen im Lösungsbereich zusammen, um einen bestimmten Geschäftlichen Wert zu erzielen.

Anwendungen und Komponenten, die an einer bestimmten Geschäftsfunktion ausgerichtet sind, bleiben von Anwendungen entkoppelt, die an anderen Geschäftsfunktionen ausgerichtet sind, da sie unterschiedliche Geschäftliche Bedenken betreffen. Eingeschränkte Kontexte werden von Geschäftsfähigkeiten abgeleitet und exklusiv zugeordnet. Sie stellen die Grenze einer Geschäftsfunktionsimplementierung dar und verhalten sich wie eine Domäne.

Wenn sich die Geschäftsfunktionen ändern, ändern sich gebundene Kontexte. Sie erwarten vorzugsweise eine vollständige Ausrichtung zwischen Domänen und entsprechenden gebundenen Kontexten, aber wie Sie in späteren Abschnitten lernen, unterscheidet sich die Realität manchmal vom Ideal.

Wenn wir die Zuordnung von Funktionen zu Tailwind Traders projizieren, können begrenzungsgebundene Kontextgrenzen und Domänenimplementierungen ähnlich wie das folgende Diagramm aussehen.

In diesem Diagramm basiert das Kundenmanagement auf Fachwissen und weiß daher am besten, welche Daten anderen Domänen dienen sollen. Die innere Architektur des Kundenmanagements wird entkoppelt, sodass alle Anwendungskomponenten innerhalb dieser Grenzen direkt über anwendungsspezifische Schnittstellen und Datenmodelle kommunizieren können.

Datenprodukte und klare Interoperabilitätsstandards werden verwendet, um die Datenverteilung an andere Domänen zu formalisieren. Bei diesem Ansatz richten sich alle Datenprodukte auch an die Domäne und erben die allgegenwärtige Sprache, die eine konstruierte, formalisierte Sprache ist, die von Projektbeteiligten und Designern aus derselben Domäne vereinbart wird, um den Anforderungen dieser Domäne gerecht zu werden.

Zusätzliche Domänen aus mehreren Funktionsrealisierungen

Es ist wichtig zu beachten, dass bei der Arbeit mit Geschäftsfähigkeitenkarten einige Geschäftsfähigkeiten mehrfach instanziiert werden können.

Beispielsweise könnten Tailwind Traders mehrere lokalisierte Realisierungen (oder Implementierungen) von "Gepäckabfertigung und verlorenen Gegenständen" haben. Gehen Sie davon aus, dass eine Zeile ihres Geschäfts nur in Asien tätig ist. In diesem Zusammenhang ist "Gepäckabfertigung und verlorene Gegenstände" eine Funktion, die für asiatisch-bezogene Flugzeuge erfüllt ist. Ein anderer Geschäftsbereich könnte auf den europäischen Markt abzielen, und in diesem Zusammenhang wird eine weitere "Gepäckverwaltung und Fundbüro"-Funktion eingesetzt. Dieses Szenario mehrerer Instanzen kann zu mehreren lokalisierten Implementierungen mit unterschiedlichen Technologiediensten und nicht zusammenhängenden Teams führen, um diese Dienste zu betreiben.

Die Beziehung zwischen Geschäftsfähigkeit und Fähigkeit-Instanzen (Realisierungen) ist eins zu viele. Aus diesem Gründen haben Sie zusätzliche (Unter-)Domänen.

Finden Sie freigegebene Funktionen und achten Sie auf freigegebene Daten

Wie Sie freigegebene Geschäftsfähigkeiten handhaben, ist wichtig. In der Regel implementieren Sie gemeinsam genutzte Funktionen zentral, als Dienstmodelle und stellen sie verschiedenen Branchen zur Verfügung. "Kundenverwaltung" kann ein Beispiel für diese Art von Funktion sein. In unserem Beispiel "Tailwind Traders" verwenden sowohl die asiatischen als auch die europäischen Geschäftszweige die gleiche Verwaltung für ihre Kunden.

Aber wie kann man den Besitz von Domänendaten auf eine geteilte Fähigkeit projizieren? Mehrere Geschäftsvertreter übernehmen wahrscheinlich die Verantwortung für Kunden innerhalb derselben Verwaltung.

Es gibt eine Anwendungsdomäne und eine Datendomäne. Ihre Domäne und ihr abgegrenzter Kontext stimmen nicht genau mit der Perspektive eines Datenprodukts überein. Sie könnten dagegen argumentieren, dass es immer noch ein einziges Datenproblem aus geschäftlicher Sicht gibt.

Für gemeinsame Funktionen wie komplexe Anbieterpakete, SaaS-Lösungen und Legacy-Systeme seien Sie in Ihrem Domänendatenbesitzansatz konsistent. Sie können den Besitz von Daten über Datenprodukte trennen, was möglicherweise Anwendungsverbesserungen erfordert. In unserem "Tailwind Traders"-Beispiel "Kundenmanagement" können verschiedene Pipelines aus der Anwendungsdomäne mehrere Datenprodukte generieren: ein Datenprodukt für alle asiatischen Kunden und eines für alle europäischen Kunden. In dieser Situation stammen mehrere Datendomänen aus derselben Anwendungsdomäne.

Sie können Ihre Anwendungsdomänen auch bitten, ein einzelnes Datenprodukt zu erstellen, das Metadaten zum Unterscheiden des Datenbesitzes innerhalb von sich selbst kapselt. Sie können z. B. einen Spaltennamen für den Besitz reservieren und jede Zeile einer einzelnen bestimmten Datendomäne zuordnen.

Identifizieren von Monolithen, die mehrere Geschäftsfunktionen bieten

Achten Sie auch auf Anwendungen, die auf mehrere Geschäftsfunktionen ausgerichtet sind, die häufig in großen und traditionellen Unternehmen zu sehen sind. In unserem Beispielszenario verwenden Tailwind Traders ein komplexes Softwarepaket, um sowohl "Kostenmanagement" als auch "Vermögenswerte und Finanzierungen" zu erleichtern. Diese gemeinsamen Anwendungen sind Monolithen, die so viele Funktionen wie möglich bereitstellen, wodurch sie groß und komplex sind. In einer solchen Situation sollte die Anwendungsdomäne größer sein. Dasselbe gilt für den gemeinsamen Besitz, in dem sich mehrere Datendomänen in einer Anwendungsdomäne befinden.

Entwurfsmuster für quellenausgerichtete, neuzustellende und verbraucherausgerichtete Domänen

Wenn Sie Ihre Domänen zuordnen, können Sie ein Muster basierend auf der Erstellung, Nutzung oder Weiterleitung Ihrer Daten auswählen. Für Ihre Architektur können Sie Vorlagen entwerfen, die Ihre Domänen basierend auf den spezifischen Merkmalen der Domäne unterstützen.

An das Quellsystem angepasste Domains

An Quellsystemen ausgerichtete Domänen sind an Quellsysteme ausgerichtet, aus denen die Daten entstehen. Diese Systeme sind in der Regel transaktions- oder betriebsbereit.

Ihr Ziel ist es, Daten direkt aus diesen goldenen Quellsystemen zu erfassen. Lesend-optimierte Datenprodukte aus Ihren bereitstellenden Domänen für intensive Datennutzung. Erleichtern Sie diese Domänen mithilfe standardisierter Dienste für die Datentransformation und -freigabe.

Diese Dienste, die vorkonfigurierte Containerstrukturen umfassen, ermöglichen Es Ihren quellorientierten Domänenteams, Daten einfacher zu veröffentlichen. Es ist der Weg des geringsten Widerstands mit minimalen Unterbrechungen und Kosten.

Verbraucherorientierte Domains

Verbraucherausgerichtete Domänen sind das Gegenteil von quellenorientierten Domänen. Sie sind an bestimmten Endbenutzeranwendungsfällen ausgerichtet, für die Daten aus anderen Domänen erforderlich sind. Vom Kunden ausgerichtete Domänen nutzen und transformieren Daten, damit sie den Anwendungsfällen Ihrer Organisation entsprechen.

Erwägen Sie, gemeinsame Datendienste für die Datentransformation und den Verbrauch anzubieten, um diese verbrauchenden Anforderungen zu erfüllen. Sie können domänenunabhängige Dateninfrastrukturfunktionen anbieten, z. B. um Datenpipelinen, Speicherinfrastruktur, Streamingdienste, analytische Verarbeitung usw. zu verarbeiten.

Erneute Zustellungsdomänen

Die Wiederverwendbarkeit von Daten ist ein anderes und schwierigeres Szenario. Wenn nachgeschaltete Verbraucher beispielsweise an einer Kombination aus Daten aus verschiedenen Domänen interessiert sind, können Sie Datenprodukte erstellen, die Daten aggregieren oder allgemeine Daten kombinieren, die von vielen Domänen benötigt werden. Auf diese Weise können Sie sich wiederholende Arbeiten vermeiden.

Erstellen Sie keine starken Abhängigkeiten zwischen Ihren Datenprodukten und analytischen Anwendungsfällen. Bemühen Sie sich stattdessen um Flexibilität und lose Kopplung. Das folgende Modell veranschaulicht, wie Sie Flexibilität erreichen können. Eine Domäne besitzt sowohl Datenprodukte als auch analytische Anwendungsfälle und hat separate Prozesse für die Erstellung von Datenprodukten und die Datennutzung entwickelt.

Definieren überlappender Domänenmuster

Die Domänenmodellierung wird häufig kompliziert, wenn Daten oder Geschäftslogik domänenübergreifend freigegeben werden. In großen Organisationen verlassen sich Domänen häufig auf Daten aus anderen Domänen. Es kann hilfreich sein, generische Domänen zu haben, die Integrationslogik auf eine Weise bereitstellen, die es anderen Unterdomänen ermöglicht, sie zu standardisieren und davon zu profitieren. Halten Sie Ihr gemeinsames Modell zwischen Unterdomänen klein und immer an der allgegenwärtigen Sprache ausgerichtet.

Für überlappende Datenanforderungen können Sie verschiedene Muster aus dem domänengesteuerten Design verwenden. Hier ist eine kurze Zusammenfassung der Muster, aus der Sie auswählen können:

• Ein separates Methodenmuster kann verwendet werden, wenn Sie die damit verbundenen Kosten der Duplizierung gegenüber der Wiederverwendbarkeit bevorzugen. Die Wiederverwendbarkeit wird für höhere Flexibilität und Agilität geopfert.
• Ein Kundenliefermuster kann verwendet werden, wenn eine Domäne stark und bereit ist, die Daten und Anforderungen der nachgeschalteten Verbraucher zu übernehmen. Zu den Nachteilen gehören widersprüchliche Bedenken und erzwingen, dass Ihre nachgelagerten Teams Lieferumsätze und Zeitplanprioritäten aushandeln.
• Ein Partnerschaftsmuster kann verwendet werden, wenn Ihre Integrationslogik in einer neu erstellten Domäne auf ungeplante Weise koordiniert wird. Alle Teams arbeiten zusammen und betrachten die Bedürfnisse der anderen. Da niemand die freigegebene Logik frei ändern kann, ist ein erhebliches Engagement von allen Beteiligten erforderlich.
• Ein konformes Muster kann verwendet werden, um alle Ihre Domänen allen Anforderungen zu entsprechen. Verwenden Sie dieses Muster, wenn Ihre Integrationsarbeit komplex ist, keine anderen Parteien kontrolle haben können oder Sie Anbieterpakete verwenden.

In allen Fällen sollten Ihre Domänen Ihren Interoperabilitätsstandards entsprechen. Eine Partnerschaftsdomäne, die neue Daten für andere Domänen erzeugt, muss ihre Datenprodukte wie jede andere Domäne verfügbar machen, einschließlich der Besitznahme.

Domänenverantwortung

Datengitter dezentralisiert den Besitz von Daten, indem es in Domänenteams verteilt wird. Für viele Organisationen bedeutet dies eine Umstellung von einem zentralisierten Modell zur Governance zu einem Verbundmodell. Domänenteams werden Aufgaben zugewiesen, z. B.:

• Verantwortung für Datenpipelines übernehmen, z. B. das Erfassen, Säubern und Transformieren von Daten, um die Bedürfnisse möglichst vieler Datenkunden zu erfüllen.
• Verbesserung der Datenqualität, einschließlich der Einhaltung von SLAs und qualitätsbezogener Maßnahmen, die von Datenkonsumenten festgelegt wurden
• Einkapselung von Metadaten oder die Verwendung reservierter Spaltennamen zur feinkörnigen Zeilen- und Spaltenfilterung
• Einhaltung von Metadatenverwaltungsstandards, einschließlich:
  • Registrierung des Anwendungs- und Quellsystemschemas
  • Metadaten zur verbesserten Auffindbarkeit
  • Versionsverwaltungsinformationen
  • Verknüpfung von Datenattributen und Geschäftsbedingungen
  • Integrität von Metadateninformationen , um eine bessere Integration zwischen Domänen zu ermöglichen
• Einhaltung von Dateninteroperabilitätsstandards, einschließlich Protokollen, Datenformaten und Datentypen
• Bereitstellung von Linien entweder durch Verknüpfen von Quellsystemen und Integrationsdiensten mit Scannern oder durch manuelle Bereitstellung von Linien
• Einhaltung von Datenfreigabeaufgaben, einschließlich IAM-Zugriffsüberprüfungen und Datenvertragserstellung

Grad der Granularität für die Entkopplung

Nachdem Sie nun wissen, wie Sie Datendomänen erkennen und vereinfachen können, können Sie lernen, die richtige Ebene der Domänen granularität und Regeln für die Entkoppelung zu entwerfen. Zwei wichtige Dimensionen spielen eine Rolle bei der Zerlegung Ihrer Architektur.

Die Granularität für funktionale Domänen und das Festlegen von gebundenen Kontexten ist eine Dimension. Domänen entsprechen einer bestimmten Arbeitsweise, stellen sicher, dass Daten für alle Domänen verfügbar werden, die gemeinsame Dienste verwenden, Besitz übernehmen, Metadatenstandards einhalten usw.

Legen Sie feinkörnige Grenzen fest, sofern möglich für die Datenverteilung. Datengesteuert zu sein bedeutet, Daten für eine intensiven Wiederverwendung bereitzustellen. Wenn Sie Ihre Grenzen zu locker machen, erzwingen Sie unerwünschte Kopplungen zwischen vielen Anwendungen und verlieren die Wiederverwendbarkeit von Daten. Versuchen Sie, jedes Mal zu entkoppeln, wenn Daten Grenzen von Geschäftsfähigkeiten überschreiten. Innerhalb einer Domäne ist eine enge Kopplung innerhalb der inneren Architektur der Domäne zulässig. Wenn jedoch die Grenzen der Geschäftsfunktionen überschritten werden, müssen Domänen entkoppelt bleiben und für die Freigabe mit anderen Domänen optimierte Datenprodukte verteilen.

Granularität für technische Domänen und Infrastrukturnutzung ist die andere wichtige Dimension. Ihre Datenlandezonen ermöglichen Agilität für die Bereitstellung von Datenanwendungen, die Datenprodukte erstellen. Wie erstellen Sie diese Art von Landungszone mit gemeinsamer Infrastruktur und Diensten darunter? Funktionale Domänen sind logisch gruppiert und gut geeignet, um die Infrastruktur der Plattform gemeinsam zu nutzen. Hier sind einige Faktoren, die Sie beim Erstellen dieser Landezonen berücksichtigen sollten:

• Zusammenhalt und Effizienz beim Arbeiten mit und Freigeben von Daten sind ein starker Faktor für die Ausrichtung funktionaler Domänen an eine Datenlandungszone. Dies bezieht sich auf die Datenschwere, die Tendenz, große Datenprodukte ständig zwischen Domänen zu teilen.
• Regionale Grenzen können dazu führen, dass zusätzliche Datenlandungszonen implementiert werden.
• Besitz-, Sicherheits- oder rechtliche Grenzen können die Domänentrennung erzwingen. Beispielsweise können einige Daten für andere Domänen nicht sichtbar sein.
• Flexibilität und Das Tempo des Wandels sind wichtige Faktoren. Einige Domänen können eine hohe Innovationsgeschwindigkeit aufweisen, während andere Domänen stark wertstabil sind.
• Funktionale Grenzen können Teams voneinander trennen. Ein Beispiel hierfür könnte quellorientierte und verbraucherorientierte Grenzen sein. Die Hälfte Ihrer Domänen-Teams schätzt möglicherweise bestimmte Dienste mehr als andere.
• Wenn Sie Ihre Fähigkeit potenziell verkaufen oder abtrennen möchten, sollten Sie eine enge Integration mit gemeinsamen Diensten aus anderen Bereichen vermeiden.
• Teamgröße, Fähigkeiten und Reife können wichtige Faktoren sein. Hochqualifizierte und ausgereifte Teams bevorzugen häufig den Betrieb ihrer eigenen Dienste und Infrastruktur, während weniger ausgereifte Teams weniger wahrscheinlich den zusätzlichen Aufwand für die Plattformwartung schätzen.

Bevor Sie viele Datenlandungszonen bereitstellen, sehen Sie sich Ihre Domänenzerlegung an und bestimmen Sie, welche funktionalen Domänen für die gemeinsame Nutzung der zugrunde liegenden Infrastruktur geeignet sind.

Zusammenfassung

Die Modellierung von Geschäftsfunktionen hilft Ihnen, Ihre Domänen in einer Datengitterarchitektur besser zu erkennen und zu organisieren. Sie bietet einen ganzheitlichen Überblick über die Art und Weise, wie Daten und Anwendungen Ihrem Unternehmen Einen Mehrwert bieten und gleichzeitig Ihnen dabei helfen, Ihre Datenstrategie und Ihre Geschäftsanforderungen zu priorisieren und zu konzentrieren. Sie können die Modellierung von Geschäftsfunktionen auch für mehr als nur Daten verwenden. Wenn beispielsweise Skalierbarkeit ein Problem darstellt, können Sie dieses Modell verwenden, um Ihre wichtigsten Kernfunktionen zu identifizieren und eine Strategie dafür zu entwickeln.

Einige Praktiker äußern die Sorge, dass das Erstellen einer Zielzustandsarchitektur, indem alles im Voraus abgebildet wird, ein aufwändiges Unterfangen ist. Stattdessen empfehlen sie, Ihre Domänen organisch zu identifizieren, während Sie sie in Ihre neue Datengitterarchitektur integrieren. Anstatt den Zielzustand von oben nach unten zu definieren, arbeiten Sie bottom-up, erkunden, experimentieren und übergehen Ihren aktuellen Zustand in einen Zielzustand. Dieser vorgeschlagene Ansatz kann zwar schneller sein, birgt jedoch erhebliche Risiken. Sie können sich ganz einfach mitten in einem komplexen Umzugs- oder Renovierungsvorgang befinden, wenn Dinge kaputtgehen. Die Arbeit in beide Richtungen, sowohl von oben nach unten als auch von unten nach oben, und dann im Laufe der Zeit in der Mitte zusammenkommen, ist ein differenzierterer Ansatz.

Nächster Schritt

• Was ist ein Datenprodukt?