• Eineindeutige (das heißt dieses Datum kommt nur ein einziges Mal vor), nicht sprechende (man kann vom Namen des Schlüssels keinen Rückschluss auf den Inhalt machen; beispielsweise sollte eine Kontonummer nicht gleichzeitig auch der Schlüssel sein)
• fachliche Schlüssel für Stamm- und Referenzdaten, welche intern erzeugt und verwaltet werden
• interne Referenzdaten, die durch das Unternehmen selbst definiert und erzeugt werden (beispielsweise interne Ratings, Risikostufen, Segmentierungen)
• externe Referenzdaten, wie extern erzeugte Schlüssel und Referenzdaten, welche von extern bezogen werden und generell oder branchenspezifisch gebräuchlich sind (beispielsweise Ländercodes, Währungscodes, NOGA-Code, externe Ratings)
Das Datensegment Produktdaten umfasst alle Definitionen von Produkten und Dienstleistung mit den dazugehörigen Geschäftslogiken (beispielsweise: ist die regulative Relevanz pro Produkt für ein „Jugendkonto“ für Personen unter 20 Jahren gegeben?).
Das Datensegment Vertriebsdaten umfasst „scharfe“ Vertriebsdaten (beispielsweise ein Kunde) und zugehörige Dateninstanzen mit interner Anreicherung oder Veredelung.
Das Datensegment Bestand umfasst „scharfe“ Bestandsdaten (beispielsweise aus Konto und Depots von Kunden) und zugehörige Dateninstanzen mit interner Anreicherung oder Veredelung.
Das Datensegment Transaktionen umfasst alle „scharfen“ Transaktionsdaten (beispielsweise einen Kundenauftrag oder Aktienkauf), und zugehörige Dateninstanzen mit interner Anreicherung oder Veredelung.
Die Erweiterungen und Verfeinerungen der Datensegmente können je nach Bedürfnis beliebig so weiter fortgeführt werden, bis man alle erforderlichen Datensegmente auf der gewünschten Detaillierungsebene identifiziert und beschrieben hat. Das hier beschriebene Vorgehen und der richtige Einsatz vom «Haus der Daten & Dokumente» unterstützen die elegante und zielgerichtete Entwicklung einer Datenstrategie - und zwar jeweils basierend auf den grundlegenden Daten und Dokumenten eines Unternehmens.
Somit schließt sich der Kreis mit dem Beginn der Geschichte zu Beginn dieses Abschnitts und gleichzeitig habe ich den Mehrwert vom Grundbegriffe-Ansatz ein weiteres Mal aufzeigen können.
3.5 Ein Datenmodell bringt den Überblick
Allgemein betrachtet dient ein Modell zur Darstellung von Dingen, Gegenständen und Objekten der realen Welt und den Zusammenhängen - also Beziehungen - zwischen diesen Objekten. Im Rahmen der semantischen Datenmodellierung dient ein Datenmodell dazu, den in einem gegebenen Kontext relevanten Ausschnitt der realen Welt - beispielsweise die benötigten Funktionen bei der Entwicklung einer Software - zu bestimmen und als Modell darzustellen.
Somit sollen die bereichsübergreifende Abstimmung, Steuerung und Weiterentwicklung von elektronischen Daten vereinfacht werden. Die Dokumentation von Daten ist ebenfalls eine Grundvoraussetzung für die Entwicklung einer Datenstrategie, wie ich später noch aufzeigen werde.
Fachliche Datenmodelle haben in der Regel eine wesentlich längere Lebensdauer als Funktionen und Prozesse und somit Software - grundsätzlich gilt hier der einfache Leitsatz: Daten sind stabil, IT-Funktionen sind es nicht.
«Das primäre Ziel der Datenmodellierung ist ein ganzheitlicher, systematischer und nachhaltiger Ansatz zur einheitlichen Dokumentation der relevanten elektronischen Daten.»
Alle fachlichen Datenmodelle bestehen aus Datenobjekten als Abbildung von Objekten der realen Welt und schafft ein vollständiges Abbild aller relevanten Daten. Dabei geht es in erster Linie darum, die reale Welt unabhängig von der IT fachlich zu beschreiben und eine bestmögliche Grundlage für die Standardisierung der Daten zu bieten.
Das fachliche, ganzheitliche Unternehmensdatenmodell aka UDM ist ein konzeptionelles, semantisches Datenmodell, welches mit Datenobjekten als Abstraktion die wesentlichen Daten des gesamten Unternehmens in einer vereinfachten und systematischen Form darstellt und so für ganzheitliche Transparenz sorgt.
Das UDM schafft für das Unternehmen eine einheitliche, methodische und inhaltliche Basis zur Steuerung und Bewirtschaftung von elektronischen Daten und deckt die vollständige inhaltliche Dimension der Steuerung und Bewirtschaftung von Daten über die Datensegmente im HDD und über alle Phasen des Datenlebenszyklus ab:
Wesentliche Anwendungsfälle für das UDM
Durch fachliche Metadaten und deren Abbildung im UDM werden die logischen Zusammenhänge von Daten (Was wird betrachtet?), Verantwortlichkeiten (Wer betrachtet die Daten?) und Business Capabilities (Welche Fähigkeiten werden gebraucht?) transparent und konsistent.
Die Zusammenhänge von Daten über die verschiedenen Geschäftsprozesse hinweg werden aufgezeigt und man erkennt frühzeitig die Auswirkungen auf Daten bei der allfälligen Anpassung von Geschäftsprozessen. Ebenso können Daten effizient bewirtschaftet und effektiv genutzt werden, und die Daten sowie Erkenntnisse verbleiben nicht „versteckt“ in Silos der Fachbereiche.
Das UDM liefert damit die nötige Auskunftsbereitschaft über die logischen Zusammenhänge von Daten und Informationen für relevante Interessengruppen.
«Das UDM schafft die methodische und inhaltliche Basis für die Steuerung und Bewirtschaftung von Daten.»
Ein fachliches Datenmodell aka FDM ist ein konzeptionelles, semantisches Datenmodell, welches mit Datenobjekten als Abstraktion die wesentlichen Daten eines oder mehrerer IT-Applikationen sowie deren Beziehungen und Eigenschaften bezogen auf einen Geschäftsprozess oder eines Fachbereichs in einer vereinfachten und systematischen Form darstellt, um die jeweiligen Datenbedürfnisse sicherzustellen.
Ein FDM erleichtert das gemeinsame Verständnis und die Kommunikation innerhalb eines sowie zwischen mehreren Geschäftsprozessen, schafft verbindliche Verantwortlichkeiten und fördert die bereichsübergreifende Konsistenz von Daten. Jedes FDM stellt eine Erweiterung - also die nächste Abstraktionsstufe - des zuvor erwähnten, fachlichen Unternehmensdatenmodells (UDM) dar.
«Mit Datenobjekten stellt man die an Geschäftsprozessen beteiligten Daten & Zusammenhänge einfacher dar.»
Ein Datenobjekt ist die einheitliche, fachliche Abstraktion und Beschreibung eines in der realen Welt tatsächlich vorhandenen oder virtuellen Gegenstandes oder Objektes, der mit elektronischen Daten abgebildet werden soll, beispielsweise ein Vertrag.
Es leitet sich aus demjenigen Geschäftsprozess ab, in welchem gemäß Erzeuger-Grundsatz das Datenobjekt erzeugt, gespeichert oder genutzt wird und dient zur Abbildung, Modellierung und Steuerung dieses Objektes.
Nachstehend zeige ich ein stark vereinfachtes Beispiel für den Einsatz von Datenobjekten im «Haus der Daten & Dokumente» (HDD):
Beispiel: Einsatz von Datenobjekten, zugeordnet im HDD
In diesem Beispiel möchte ich gerne anhand der Ausstellung eines Vertrages für ein (beliebiges) Produkt und einen (beliebigen) Kunden den Einsatz von Datenobjekten und deren Verknüpfungen im HDD illustrieren.
Als erstes wird der Vertrag für ein bestimmtes Produkt und einen bestimmten Kunden in einer IT-Applikation als ein strukturierter Datensatz angelegt. Aus diesem Datensatz wird in einer anderen IT-Applikation eine elektronische Vertragsvorlage befüllt und dem Kundenbetreuer als Vertragsentwurf zur Durchsicht, Vervollständigung und Abnahme vorgelegt.
Der Kundenbetreuer druckt dann diesen Vertrag als „Unsignierten Vertrag“ aus und schickt diesen dem Kunden per Post (in diesem konkreten Fall gehe ich tatsächlich von Snail-Mail aus) zur Prüfung und Unterschrift zu. Nach einiger Zeit