Datendomänen

Das Datengittermodell, im Kern, wird in der Dezentralisierung und der Verteilung der Verantwortung auf Domänen gegründet. Wenn Sie diesen Teil des Unternehmens wirklich verstehen, sind Sie am besten positioniert, um die zugehörigen Daten zu verwalten und ihre Genauigkeit sicherzustellen. Dies ist das Prinzip des domänenorientierten Dateneigentums.

Um das domänenorientierte Dateneigentum zu fördern, müssen Sie zuerst eine Zerlegung Ihrer Datenarchitektur vornehmen. Der Datengittermodell-Gründer Zhamak Dehghani fördert den domänengesteuerten Design-Ansatz (Domain-Driven Design, DDD) 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. Er wurde ursprünglich nicht erstellt, um Unternehmensdaten zu modellieren, und für Datenverwaltungsfachleute kann seine Methode abstrakt und technisch sein. Es gibt auch oft einen Mangel an Verständnis von DDD. Die Fachleute finden seine konzeptionellen Vorstellungen zu schwer zu erfassen, oder versuchen, Beispiele aus der Softwarearchitektur oder objektorientierten Programmierung auf ihre Datenlandschaft zu projizieren. In diesem Artikel erhalten Sie pragmatische Anleitungen und klares Vokabular, damit Sie DDD verstehen und verwenden können.

Domänengesteuertes Design

Von Eric Evans eingeführt, ist domänengesteuertes Design eine Methode zur Unterstützung der Softwareentwicklung, die dabei hilft, komplexe Systeme für größere Organisationen zu beschreiben. DDD ist beliebt, da viele seiner Praktiken auf hoher Ebene moderne Software- und Anwendungsentwicklungsansätze für Dinge wie Microservices beeinflussen.

DDD unterscheidet zwischen gebundenen Kontexten, Domänen und Unterdomänen. Domänen sind Problemorte, um die Sie sich kümmern müssen. Sie sind Bereiche, in denen Wissen, Verhalten, Gesetze und Aktivitäten zusammenkommen. Sie sehen die 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 geteilte Sprache wird als die ubiquitäre Sprache oder Domänensprache bezeichnet.

Domänen werden in Unterdomänen unterteilt, um die Komplexität besser zu verwalten. Ein gängiges Beispiel hierfür ist die Zerlegung eines Bereichs in Unterbereiche, die jeweils einem bestimmten Geschäftsproblem entsprechen, wie unter Operationalisieren eines Datengittermodells für die domänengesteuerte KI/ML-Featurisierung gezeigt.

Nicht alle Unterdomänen sind identisch. Sie können z. B. Domänen klassifizieren, die entweder Kern, generisch oder unterstützend sind. Kerndomänen sind die wichtigsten. Sie sind die geheime Zutat, die eine Organisation einzigartig machen. Generische Unterdomänen sind nicht spezifisch und in der Regel einfach mit Standard-Produkten zu lösen. Die Unterstützung von Unterdomänen bietet keinen Wettbewerbsvorteil, ist jedoch erforderlich, um eine Organisation am Laufen zu halten, und sind in der Regel 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ösungsraum sinnvoll ist. Innerhalb von DDD kann das Code, Datenbankdesigns usw. umfassen. Zwischen den Domänen und gebundenen Kontexten kann eine Ausrichtung vorhanden sein, es gibt keine feste Regelbindung der beiden. Gebundene Kontexte sind technisch und können mehrere Domänen und Unterdomänen umfassen.

Empfehlungen zur Domänenmodellierung

Wenn Sie Datengittermodelle als Konzept für die Demokratisierung von Daten übernehmen und das Prinzip des domänenorientierten Dateneigentums implementieren, um Flexibilität zu erhöhen, wie funktioniert dies in der Praxis? Wie sieht ein Übergang von Unternehmensdatenmodellierung zu domänengesteuerter Designmodellierung aus? Welche Lektionen können Sie von DDD für die Datenverwaltung übernehmen?

Erstellen Sie einer funktionale Geschäftskomposition Ihrer Problemort

Bevor Sie es Ihren Teams erlauben, ihre Daten Ende zu Ende zu betreiben, schauen Sie sich den Umfang an und verstehen Sie die Problemorte, um die Sie sich kümmern möchten. Es ist wichtig, diese Übung zuerst durchzuführen, bevor Sie sich mit den Details einer technischen Implementierung beschäftigen. Wenn Sie logische Grenzen zwischen diesen Problemorten festlegen, werden Zuständigkeiten klarer und können besser verwaltet werden.

Schauen Sie sich Ihre Geschäftsarchitektur beim Gruppieren Ihrer Problemorte an. 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 erzielen. Diese Abstraktion setzt Daten, Prozesse, Organisation und Technologie in einen bestimmten Kontext, in Übereinstimmung mit den strategischen Geschäftszielen und Zielen Ihrer Organisation. Eine Geschäftsfunktionskarte zeigt, welche Funktionsbereiche notwendig sind, um Ihre Mission und Vision zu erfüllen.

Sie können die Funktionszerlegung eines fiktiven Unternehmens, Tailwind Traders, im folgenden Modell ansehen.

Tailwind Traders müssen alle funktionsspezifischen Bereiche, die in der Zuordnung der Geschäftsfunktion aufgeführt sind, erfolgreich meistern. Tailwind Traders müssen z. B. Tickets als Teil von Online- oder Offline-Ticket-Management-Systemen verkaufen können über Piloten verfügen, die im Rahmen eines Pilotenmanagementprogramms Flugzeuge fliegen. Das Unternehmen kann einige Aktivitäten auslagern und andere als Kern seines Unternehmens behalten.

In der Praxis werden Sie beobachten, dass die meisten Ihrer Mitarbeiter um Geschäftsfunktionen herum organisiert sind. Personen, die an derselben Geschäftsfunktion arbeiten, teilen das gleiche Vokabular. Das gleiche gilt für Ihre Anwendungen und Prozesse, die in der Regel gut ausgerichtet und eng 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

Stimmen Sie zur besseren Verwaltung Ihrer Unternehmensarchitektur Ihre Geschäftsfunktionen, gebundenen Kontexte und Anwendungen aufeinander ab. Es ist wichtig, dabei einige Grundregeln zu befolgen.

Geschäftsfunktionen müssen auf der geschäftlichen Ebene und abstrakt bleiben. Sie stellen dar, was Ihre Organisation macht und sind auf Ihre Problemorte ausgerichtet. Wenn Sie eine Geschäftsfunktion implementieren, wird eine Realisierung (Funktionsinstanz) für einen bestimmten Kontext erstellt. Mehrere Anwendungen und Komponenten arbeiten innerhalb solcher Grenzen in Ihrem Lösungsbereich zusammen, um spezifischen Geschäftswert zu liefern.

Anwendungen und Komponenten, die auf eine bestimmte Geschäftsfunktion abgestimmt sind, bleiben von Anwendungen entkoppelt, die auf andere Geschäftsfunktionen abgestimmt, da sie unterschiedliche geschäftliche Bedenken betreffen. Gebundene Kontexte werden von geschäftsspezifischen Funktionen abgeleitet und diesen ausschließlich zugeordnet. Sie stellen die Grenze einer Geschäftsfunktionsimplementierung dar, und sie verhalten sich wie eine Domäne.

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

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

In diesem Diagramm basiert die Kundenverwaltung auf Fachkompetenz 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. In diesem Ansatz stimmen alle Datenprodukte auch mit der Domäne überein 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 zu dienen.

Zusätzliche Domänen aus mehreren Funktionen-Realisierungen

Wenn Sie mit Geschäftsfunktionen arbeiten, ist es wichtig zu erkennen, dass einige Geschäftsfunktionen mehrmals instanziiert werden können.

Als Beispiel könnte Tailwind Traders mehrere lokalisierte Realisierungen (oder Implementierungen) von „Gepäckhandhabung und verlorene Gegenstände“ haben. Gehen Sie davon aus, dass eine Branche des Unternehmens nur in Asien tätig ist. In diesem Zusammenhang ist „Gepäckhandhabung und verlorene Gegenstände“ eine Funktion, die für asiatische Flugzeuge erfüllt ist. Eine andere Branche könnte auf den europäischen Markt abzielen, und in diesem Zusammenhang wird eine weitere „Gepäckhandhabung und verlorene Gegenstände“ verwendet. Dieses Szenario mehrerer Instanzen kann zu mehreren lokalisierten Implementierungen führen, die unterschiedliche Technologiedienste und nichtzusammenhängende Teams nutzen, um diese Dienste zu betreiben.

Die Beziehung von Geschäftsfunktionen und Funktionsinstanzen (Realisierungen) ist 1:n. Aus diesem Grund haben Sie zusätzliche (Unter-)Domänen.

Suchen nach gemeinsam genutzten Funktionen und Daten

Es ist von Bedeutung, wie Sie freigegebene Geschäftsfunktionen behandeln. In der Regel werden gemeinsam genutzte Funktionen zentral in Form von Servicemodellen implementiert und den verschiedenen Branchen zur Verfügung gestellt. „Kundenverwaltung“ kann ein Beispiel für diese Art von Funktion sein. In unserem Beispiel von Tailwind Traders verwenden sowohl die asiatischen als auch die europäischen Branchen dieselbe Verwaltung für ihre Kunden.

Aber wie können Sie Domänendateneigentum auf eine gemeinsam genutzten Funktion projizieren? Mehrere Geschäftsvertreter berücksichtigen wahrscheinlich die Verantwortlichkeit für Kunden, die innerhalb derselben gemeinsamen Verwaltung vorhanden sind.

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

Bei gemeinsam genutzten Funktionen wie komplexen Anbieterpaketen, SaaS-Lösungen und Legacy-Systemen sollten Sie einen einheitlichen Ansatz für das Eigentum von Domänendaten verfolgen. Sie können Dateneigentum über Datenprodukte trennen, was möglicherweise Anwendungsverbesserungen erfordert. In unserem Beispiel von Tailwind Traders zum Kundenmanagement können verschiedene Pipelines aus der Anwendungsdomäne mehrere Datenprodukte generieren: ein Datenprodukt für alle asiatischen Kunden und eins für alle europabezogenen Kunden. In dieser Situation stammen mehrere Datendomänen aus derselben Anwendungsdomäne.

Sie können Ihre Anwendungsdomänen auch auffordern, ein einzelnes Datenprodukt zu erstellen, das Metadaten zur Unterscheidung der Dateneigentümerschaft in sich selbst kapselt. Sie können z. B. einen Spaltennamen für das Eigentum reservieren, wodurch jede Zeile einer einzelnen bestimmten Datendomäne zugeordnet wird.

Identifizieren von Monolithen, die mehrere Geschäftsfunktionen bieten

Achten Sie auch auf Anwendungen, die auf mehrere Geschäftsfunktionen ausgerichtet sind, die es häufig in großen und traditionellen Unternehmen gibt. In unserem Beispielszenario verwendet Tailwind Traders ein komplexes Softwarepaket, um sowohl „Kostenmanagement“ als auch „Vermögenswerte und Finanzierung“ zu ermöglichen. Diese freigegebenen 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 gemeinsames Eigentum, bei dem sich mehrere Datendomänen in einer Anwendungsdomäne befinden.

Entwurfsmuster für quellenorientierte, erneut übermittelte und verbraucherorientierte Domänen

Wenn Sie Ihre Domänen zuordnen, können Sie ein Muster basierend auf der Erstellung, dem Verbrauch oder der Neuübermittlung Ihrer Daten auswählen. Für Ihre Architektur können Sie basierend auf den spezifischen Eigenschaften der Domänen Vorlagen gestalten, die Ihre Domänen unterstützen.

Am Quellsystem ausgerichtete Domänen

Am Quellsystem ausgerichtete Domänen sind an den Quellsystemen ausgerichtet, aus denen die Daten stammen. Diese Systeme sind in der Regel transaktional oder betriebsfähig.

Ihr Ziel ist es, Daten direkt aus diesen goldenen Quellsystemen zu erfassen. Optimieren Sie Datenprodukte aus Ihrer Bereitstellung von Domänen für intensiven Datenverbrauch fürs Lesen. Ermöglichen Sie diese Domänen mithilfe standardisierter Dienste für die Datentransformation und -freigabe.

Mit diesen Diensten, zu denen auch vorkonfigurierte Containerstrukturen gehören, können Ihre quellenorientierten Domänenteams Daten einfacher veröffentlichen. Es ist der Weg des geringsten Widerstands mit minimaler Unterbrechung und Kosten.

Verbraucherorientierte Domänen

Verbraucherorientierte Domänen sind das Gegenteil von am Quellsystem ausgerichtete Domänen. Sie werden an bestimmten Anwendungsfällen des Endbenutzers ausgerichtet, die Daten aus anderen Domänen erfordern. Kundenorientierte Domänen nutzen und transformieren Daten, um den Anwendungsfällen Ihrer Organisation gerecht zu werden.

Ziehen Sie in Erwägung, gemeinsam genutzte Datendienste für die Transformation und Nutzung von Daten anzubieten, um diese Bedürfnisse zu befriedigen. Sie können beispielsweise Domänen-agnostische Dateninfrastrukturfunktionen anbieten, um Datenpipelinen, Speicherinfrastruktur, Streamingdienste, analytische Verarbeitung usw. zu handhaben.

Erneut übermittelte Domänen

Die Wiederverwendbarkeit von Daten ist ein anderes und schwierigeres Szenario. Wenn die nachgelagerten Verbraucher beispielsweise an einer Kombination aus Daten aus verschiedenen Domänen interessiert sind, können Sie Datenprodukte erstellen, die Daten aggregieren, oder Daten auf hoher Ebene kombinieren, die von vielen Domänen benötigt werden. So 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. Im folgenden Modell wird veranschaulicht, wie Sie Flexibilität erreichen können. Eine Domäne übernimmt sowohl Datenprodukte als auch analytische Anwendungsfälle und hat separate Prozesse für die Datenerstellung und die Datennutzung entwickelt.

Definieren überlappender Domänenmuster

Die Domänenmodellierung wird häufig kompliziert, wenn Daten oder Geschäftslogik über Domänen freigegeben werden. In großen Organisationen sind Domänen häufig auf Daten aus anderen Domänen angewiesen. 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 den Subdomänen klein und immer auf die ubiquitäre Sprache abgestimmt.

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

• Wenn Sie die mit der Duplizierung verbundenen Kosten der Wiederverwendbarkeit vorziehen, können Sie ein Muster separate Wege verwenden. Die Wiederverwendbarkeit wird für höhere Flexibilität und Agilität geopfert.
• Ein Muster Kundenanbieter kann verwendet werden, wenn eine Domäne stark ist und bereit ist, die Daten und Bedürfnisse der nachgelagerten Verbraucher zu übernehmen. Zu den Nachteilen gehören widersprüchliche Anliegen und der Zwang für Ihre nachgelagerten Scrum Teams, über Ergebnisse und Terminprioritäten zu verhandeln.
• Ein Muster Partnerschaft kann verwendet werden, wenn Ihre Integrationslogik auf ungeplante Weise innerhalb einer neu erstellten Domäne koordiniert wird. Alle Teams arbeiten zusammen und betrachten die Bedürfnisse der anderen. Da niemand die gemeinsam genutzte Logik frei ändern kann, wird erhebliche Zusage von allen beteiligten Personen benötigt.
• Ein Muster konform kann verwendet werden, damit alle Ihre Domänen allen Anforderungen entsprechen. Verwenden Sie dieses Muster, wenn Ihre Integrationsarbeit komplex ist, wenn keine anderen Parteien Kontrolle haben dürfen oder wenn 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 erstellt, müssen ihre Datenprodukte wie alle anderen Domänen verfügbar machen, einschließlich des Eigentums.

Zuständigkeiten von Domänen

Das Datengittermodell dezentralisiert Dateneigentum, indem es unter Domänenteams verteilt wird. Für viele Organisationen bedeutet dies eine Verschiebung von einem zentralen Modell zur Governance in ein Verbundmodell. Domänenteams werden Aufgaben zugewiesen, z. B.:

• Übernehmen von Datenpipelinen, z. B. Erfassung, Reinigung und Transformation von Daten, um so viele Anforderungen des Kunden wie möglich zu erfüllen
• Verbessern der Datenqualität, einschließlich der Einhaltung von SLAs und Qualitätsmaßnahmen, die von den Datenkunden festgelegt sind
• Kapseln von Metadaten oder Verwenden reservierter Spaltennamen für die Filterung von Feinkornzeilen und Spaltenebene
• Einhalten der Metadaten-Verwaltungsstandards, einschließlich:
  • Registrierung des Anwendungs- und Quellsystemschemas
  • Metadaten für verbesserte Erkennungsfähigkeit
  • Versionsinformationen
  • 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
• Bereitstellen von Datenherkunft entweder durch Verknüpfen von Quellsystemen und Integrationsdienste an Scanner oder durch manuelles Bereitstellen von Datenherkunft
• Einhaltung von Aufgaben zur Datenfreigabe, einschließlich IAM-Zugriffsüberprüfungen und Datenvertragserstellung

Grad der Granularität für die Entkoppelung

Jetzt da Sie wissen, wie Sie Datendomänen erkennen und ermöglichen können, können Sie lernen, die richtige Ebene der Domänengranularität und -regeln für die Entkopplung zu entwerfen. Zwei wichtige Dimensionen sind von Bedeutung, wenn Sie Ihre Architektur zerlegen.

Die Granularität für funktionsbezogene Domänen und die Einstellung gebundener Kontexte ist eine Dimension. Domänen entsprechen einer bestimmten Arbeitsweise, wobei sichergestellt wird, dass Daten für alle Domänen zur Verfügung stehen, die gemeinsame Dienste verwenden, das Eigentum übernehmen, die Metadatenstandards einhalten und so weiter.

Legen Sie, soweit möglich, feinkörnige Grenzen für die Datenverteilung fest. Wenn Daten gesteuert werden, geht es darum, Daten für die intensive Wiederverwendung verfügbar zu machen. Wenn Sie die Grenzen zu locker ziehen, erzwingen Sie unerwünschte Kopplungen zwischen vielen Anwendungen und verlieren die Wiederverwendbarkeit von Daten. Immer wenn Daten die Grenzen von Geschäftsfunktionen überschreiten, sollte eine Entkopplung angestrebt werden. Innerhalb einer Domäne ist eine enge Kopplung innerhalb der inneren Architektur der Domäne zulässig. Beim Überschreiten der Grenzen der Geschäftsfunktionen müssen Domänen jedoch entkoppelt bleiben und leseoptimierte Datenprodukte für die Freigabe mit anderen Domänen verteilen.

Die Granularität für technische Domänen und die Nutzung der Infrastruktur ist die andere wichtige Dimension. Ihre Datenzielzonen ermöglichen Flexibilität bei der Wartung von Datenanwendungen, die Datenprodukte erstellen. Wie erstellen Sie diese Art von Zielzone mit freigegebener Infrastruktur und darunterliegenden Diensten? Funktionale Domänen werden logisch gruppiert und sind gute Kandidaten für die Freigabeplattforminfrastruktur. Hier sind einige Faktoren zu berücksichtigen, die beim Erstellen dieser Zielzonen berücksichtigt werden:

• Der Zusammenhalt und die Effizienz bei der Arbeit mit und der Freigabe von Daten ist ein starker Treiber für die Ausrichtung funktionaler Domänen an eine Datenzielzone. Dies betrifft die Data Gravity, die Tendenz, große Datenprodukte ständig zwischen Domänen zu teilen.
• Regionale Grenzen können dazu führen, dass zusätzliche Datenzielzonen implementiert werden.
• Das Eigentum, die Sicherheit oder die rechtlichen Grenzen können die Trennung von Domänen erzwingen. Beispielsweise können einige Daten nicht für andere Domänen sichtbar sein.
• Flexibilität und das Tempo der Veränderung sind wichtige Treiber. Einige Domänen können eine hohe Geschwindigkeit der Innovation haben, während andere Domänen starke Wertstabilität besitzen.
• Funktionale Grenzen können Teams voneinander trennen. Ein Beispiel dafür könnten quellenorientierte und verbraucherorientierte Grenzen sein. Die Hälfte Ihrer Domänenteams kann bestimmte Dienste für andere Werte nutzen.
• Wenn Sie ihre Funktion potenziell verkaufen oder trennen möchten, sollten Sie die enge Integration mit freigegebenen Diensten aus anderen Domänen vermeiden.
• Teamgröße, Fähigkeiten und Reife können wichtige Faktoren sein. Hochqualifizierte und reife Teams bevorzugen häufig ihre eigenen Dienste und Infrastruktur, während weniger reife Teams weniger wahrscheinlich den zusätzlichen Aufwand für die Plattformwartung schätzen.

Bevor Sie viele Datenzielzonen bereitstellen, sehen Sie sich Ihre Domänenzerlegung an und bestimmen Sie, welche funktionalen Domänen Kandidaten für die Freigabe zugrunde liegender Infrastruktur sind.

Zusammenfassung

Die Modellierung von Geschäftsfunktionen hilft Ihnen, Ihre Domänen in einer vermaschten Datenarchitektur besser zu erkennen und zu organisieren. Es bietet eine ganzheitliche Sicht auf die Art und Weise, wie Daten und Anwendungen Ihrem Unternehmen Mehrwert bieten, während Sie gleichzeitig Ihre Datenstrategie und Geschäftsanforderungen priorisieren und konzentrieren können. Sie können auch die Modellierung der Geschäftsfunktionen für mehr als nur Daten verwenden. Wenn die Skalierbarkeit beispielsweise ein Problem ist, können Sie dieses Modell verwenden, um Ihre wichtigsten Kernfunktionen zu identifizieren und eine Strategie für sie zu entwickeln.

Einige Fachleute äußern die Befürchtung, dass der Aufbau einer Zielzustandsarchitektur, bei der alles im Voraus abgebildet wird, sehr aufwendig. Stattdessen empfehlen sie, dass Sie Ihre Domänen organisch identifizieren, während Sie sie in Ihre neue vermaschte Datenarchitektur integrieren. Anstatt den Zielzustand von oben nach unten zu definieren, arbeiten Sie von unten nach oben, wobei Sie erkunden, experimentieren und von Ihrem aktuellen Zustand zu einem Zielzustand übergehen. Der vorgeschlagene Ansatz mag zwar schneller sein, birgt aber erhebliche Risiken. Es kann leicht passieren, dass Sie mitten in einem komplexen Umzug oder einer Umstrukturierung stecken, wenn plötzlich etwas nicht mehr funktioniert. Die Arbeit in beide Richtungen, von oben nach unten und von unten nach oben, und dann im Laufe der Zeit ein Treffen in der Mitte ist ein nuancierterer Ansatz.

Nächster Schritt

• Was ist ein Datenprodukt?